I'm pretty new to Scala, but impressed with what I have seen so far. I'm a long-time modern Perl developer (which also has traits) and Lisp user (with a preferred functional approach), so it's nice to find something that has the right features in the right places with impressively good performance.
I'm the main developer on a project at the Ontario Institute for Cancer Research, which is using Scala and Lift, with MongoDB behind. The application is a bit about genomics (hence large complex data) and a bit about clinical data (hence security). We're finding Lift more of an issue at present, as it is fairly huge and fairly different to other web frameworks, with an element of constant change and documentation that could be a bit clearer in a few key places. The learning curve is a little steep, but I'm getting up OK at the moment. We did look at more traditionally structured frameworks, but there seem to be many promising characteristics to Lift, so right now we're just going with it.
On Thursday, 8 September 2011 19:10:03 UTC-4, TylerWeir wrote:
> Sounds like a cool project, any more details you can share.
Sure, here goes. Essentially, we are building a platform to assist in management of clinical trials in personalized medicine. The kind of trial we're involved in, involves asking patients for samples which we run through some DNA analysis to identify likely mutations that can help a clinician to select an appropriate treatment. In the field we're working in initially, there are some useful chemotherapy drugs that can target particular mutated pathways, so once we know which mutations (if we find one) are present, we can prepare a report for a clinician. So we need to track samples, record certain bits of clinical information, all securely, and associate the output with the contents of a substantial mutation database to provide a customized report. There's a lot of workflow management in this, with email notifications, auditing data, and so on. Because these are clinical trials, there is also a significant research focus, we want to be able to analyze the data in interesting ways, tracking performance targets, and so on.
We have a fairly complete system written in Grails up and running, but for various reasons it isn't completely satisfactory. The dynamic typing leads to a much greater risk of runtime errors, and the testing of views is not as good as I'd like. Personally, I like some of Grails, but its programming by convention has proven to be an issue because there is so much tacit knowledge. (A few days back, I found code that was broken simply because calling a constructor with one type of parameter enabled a whole magic data binding system we didn't even know about, resulting in ghost parameters in the request.) Lift, thanks to Scala, is nicely testable, with a very flexible but strong type system, and its use of snippets means we don't have enough control flow in the views to mean that testing is an issue. Groovy doesn't have traits either, and since previously I worked with the Perl Catalyst framework, which uses them extensively, they are proving invaluable to organize a complex system for DRYness.
Lift questions may well be forthcoming :-) I try to solve them myself, as much as anything because I need to understand Scala and Lift better, and reading the code is fascinating. But many thanks for the offer and I am sure I will take you up on it.
On Fri, Sep 9, 2011 at 8:52 AM, morungos <morun...@googlemail.com> wrote: > On Thursday, 8 September 2011 19:10:03 UTC-4, TylerWeir wrote:
>> Sounds like a cool project, any more details you can share.
> Sure, here goes. Essentially, we are building a platform to assist in > management of clinical trials in personalized medicine. The kind of trial > we're involved in, involves asking patients for samples which we run through > some DNA analysis to identify likely mutations that can help a clinician to > select an appropriate treatment. In the field we're working in initially, > there are some useful chemotherapy drugs that can target particular mutated > pathways, so once we know which mutations (if we find one) are present, we > can prepare a report for a clinician. So we need to track samples, record > certain bits of clinical information, all securely, and associate the output > with the contents of a substantial mutation database to provide a customized > report. There's a lot of workflow management in this, with email > notifications, auditing data, and so on. Because these are clinical trials, > there is also a significant research focus, we want to be able to analyze > the data in interesting ways, tracking performance targets, and so on. > We have a fairly complete system written in Grails up and running, but for > various reasons it isn't completely satisfactory. The dynamic typing leads > to a much greater risk of runtime errors, and the testing of views is not as > good as I'd like. Personally, I like some of Grails, but its programming by > convention has proven to be an issue because there is so much tacit > knowledge. (A few days back, I found code that was broken simply because > calling a constructor with one type of parameter enabled a whole magic data > binding system we didn't even know about, resulting in ghost parameters in > the request.) Lift, thanks to Scala, is nicely testable, with a very > flexible but strong type system, and its use of snippets means we don't have > enough control flow in the views to mean that testing is an issue. Groovy > doesn't have traits either, and since previously I worked with the Perl > Catalyst framework, which uses them extensively, they are proving invaluable > to organize a complex system for DRYness. > Lift questions may well be forthcoming :-) I try to solve them myself, as > much as anything because I need to understand Scala and Lift better, and > reading the code is fascinating. But many thanks for the offer and I am sure > I will take you up on it.
On Fri, Sep 9, 2011 at 5:52 AM, morungos <morun...@googlemail.com> wrote: > On Thursday, 8 September 2011 19:10:03 UTC-4, TylerWeir wrote:
>> Sounds like a cool project, any more details you can share.
> Sure, here goes. Essentially, we are building a platform to assist in > management of clinical trials in personalized medicine. The kind of trial > we're involved in, involves asking patients for samples which we run through > some DNA analysis to identify likely mutations that can help a clinician to > select an appropriate treatment. In the field we're working in initially, > there are some useful chemotherapy drugs that can target particular mutated > pathways, so once we know which mutations (if we find one) are present, we > can prepare a report for a clinician. So we need to track samples, record > certain bits of clinical information, all securely, and associate the output > with the contents of a substantial mutation database to provide a customized > report. There's a lot of workflow management in this, with email > notifications, auditing data, and so on. Because these are clinical trials, > there is also a significant research focus, we want to be able to analyze > the data in interesting ways, tracking performance targets, and so on.
> We have a fairly complete system written in Grails up and running, but for > various reasons it isn't completely satisfactory. The dynamic typing leads > to a much greater risk of runtime errors, and the testing of views is not as > good as I'd like. Personally, I like some of Grails, but its programming by > convention has proven to be an issue because there is so much tacit > knowledge. (A few days back, I found code that was broken simply because > calling a constructor with one type of parameter enabled a whole magic data > binding system we didn't even know about, resulting in ghost parameters in > the request.) Lift, thanks to Scala, is nicely testable, with a very > flexible but strong type system, and its use of snippets means we don't have > enough control flow in the views to mean that testing is an issue. Groovy > doesn't have traits either, and since previously I worked with the Perl > Catalyst framework, which uses them extensively, they are proving invaluable > to organize a complex system for DRYness.
Have you looked at LiftScreen and Wizard for managing forms including multi-page forms?
> Lift questions may well be forthcoming :-) I try to solve them myself, as > much as anything because I need to understand Scala and Lift better, and > reading the code is fascinating. But many thanks for the offer and I am sure > I will take you up on it.
On Friday, 9 September 2011 12:16:19 UTC-4, David Pollak wrote:
> Have you looked at LiftScreen and Wizard for managing forms including > multi-page forms?
I've seen them, and they looked a great base to build on, and much better than the misery I went through with single forms for multiple tables in Grails. I don't think I can use them completely out of the box, as we need to have the fields displayed determined and defined by the database rather than from the record definition. There are going to have to be some compromises here in the Scala typing. But when I get to that stage, I'll be looking to see if I use this as a base. It looks like I'll be modifying the addFields behaviour at least.
Thanks for the pointer - it's been useful to get a look at that and start thinking about it
