Scala Experience ReportMark Needham and Liz Douglass
Funny image?
Funny image?
Does it really speed                               up the development                               as was hoped?Should th...
TestingTemplating Domain
Unit testing
Functional Testing
Test DSL
First class functions
Test DSL
# of unit tests:         449# of integration tests:         280# of functional tests:         353
Unit testing
Unit testing
Unit testing
Scalatra   Scalate
SSP                      scamlScalatra   Scalate                       jade                     Mustache
View Helper
Presentation Model
More XML
More XML
And not just XML…
Going too far!
TraitsWhich example was this supposed to be?ContentRepository - JUNE
Traits1. Utilities
Traits2. Presentation Model
Traits3. Helpers to Helpers
Traits4. Wanna be objects
Traits5. Type container
Traits6. Traits with standards
Tendency to     have fewer        testsRefactoring                       Code                  discoverability
In Retrospect …
Does it really speed                               up the development                               as was hoped?Should th...
Scala compiler slower than    Java’s
Scala: An experience report
Scala: An experience report
Scala: An experience report
Upcoming SlideShare
Loading in …5

Scala: An experience report


Published on

An experience report after using scala for 6 months.

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Code revisions used for captures: June: 5579b16f8c5a8de4ee643cd0625f1050b9ffcb9dSept: 6e5c52efeceb9061dbef5e70873d8704475cba5fNov:136e27243ee3e6d3620cb06a1085b163e78fe94f
  • Who are we? What are we building?
  • Who are we? What are we building?
  • FEEDBACK, MAINTAINABILITY, INCREMENTAL AND ITERATIVE "the key factor is iterative and incremental development. How do we get feedback fast without the software getting so impenetrable that the project grinds to a halt or grinds on endlessly in mediocrity. So, testing, TDD, refactoring, build and deployment automation, etcetc, and all the teamwork practices a technical team needs to do that well and continually improve: retrospectives, collaborative design, egoless development, specification by example, etc."
  • Testing ScalaTestFirst class functionsTemplatingScalateLogic in templatesDomain Xml supportTraitsImplicitsPattern matchingOptions
  • Liz to make better stickies! Note here to the audience about keeping an eye out for when this is from
  • ** Get code coverage metrics? * Do we need to mention the other testing frameworks?
  • We chose to use scalatest – it’s quite similar in style to rspec which a couple of people were familiar with. Specs2 seemed a bit confusing and Junit didn’t really seem to be the way to go if we were really embracing scala!
  • Nice testsUsing ScalaTest with should matchersSimilar to rspecBig frameworkIntegrates with SBTWhen we started the application was really simple so a lot of our unit tests ended up looking like this. Almost pointless…
  • Also nice vanilla usageScala test works well at all levels of testing
  • Moved to DSLDo we want to talk about anything else test wise for Sept?
  • Given, when and then are aliasesThe runner function has a pass by name argument that gives us a DSLThanks Mustaq!
  • Moved to DSLDo we want to talk about anything else test wise for Sept?
  • Jumping to where we are in NovemberDriving stories from functional tests firstNot really much meat in the unit tests Integration tests testing our DB and other integration points
  • Going back to this oneNot very meatyThere is a tendency to skip them
  • However, there have been consequences of not doing very many unit testsThis is a trait that had no unit tests
  • But the ripple effect of changing it was quite large
  • We’re using a web framework called scalatra which is effectively a port of the ruby sinatra framework
  • James Strachan has written a templating plugin architecture called scalate which seems to be the defacto for scalatra and you can choose which flavour of template you use…
  • So there are 4 main choices that you have…
  • So this is how we started off back in June with Mustache.
  • No logic at all in the templatesHad to work around it and do things like the translations inside the presentation model objects – eeew.
  • Welcome Jade. Strachan convinces us with the video
  • Now we can have some helper functions that are used by the templates to do translation
  • Build time >10 minutesInvestigating, possible parallelizationIncreasing amount of logic in the templates! See Book.jade
  • This seems to be designed like the query side of CQRS?
  • Decided not to bother synchronizing the XML into objects with properties since it’s very unlikely we’ll ever move away from an xml driven approach. The licence cost for the database is in the millions and all the data in the organisation is in xml so it makes sense.
  • Most Presentation model objects are justXmlstillNote OptionalString
  • We had a pattern where if we got an empty XML element then we didn’t want to show that bit of presentation logic on the page so we made an OptionalString function to make it easier to re-use that everywhere
  • Journal looks like its got the mostlogic in it in order to work out the volume ranges. There is a little bit of A++ logic in the codeMost Presentation model objects are justXmlstill
  • Lots more LogicAs we saw earlier though the unit testing is quite minimal.
  • Java interface style to begin with
  • Traits explosion! We have 6 different usage patterns!! No wonder there was confusion over the usages (inheritance, interfaces etc)We have several of these types of traitsIn this case the PropertyLoader is mixing in the ResourceSupport traitThis is an example of an “The Introvert Trait: These are traits that aren’t intended for changing the behavior of a class for outside clients of the class, but for the code inside the class itself.” (
  • This is the main pattern of usage of traits in our presentation model/ domain Authors has the authorNames abstract memberAuthors has some private, protected and public stuffBook mixes in AuthorsWhat’s good:We can reuse authors for the other content typesThe public interface for books looks quite good: book.authorFullNames makes sense There is a unit test for Authors and a unit test for Book (which doubly tests Authors)What’s bad:This is using Inheritance-based composition (according to Scala in Depth pg 98)This means that a Book instance is also an instance of Authors and this doesn’t make any sense. We wouldn’t expect to see a book in a list of Authors for exampleWe have little encapsulation – but does this matter for a presentation model? composition would be better here
  • Is this a “Jigsaw Puzzle Trait:” example? ( : “In this pattern traits are used to separate different aspects of a responsibility in a very fine grained manner. The results are traits that are really hard to understand on their own. Actually they are easy to understand since the often only consist of half a dozen lines of code. What is difficult is to understand how this can be useful in any way. ”There are 2 usages of this trait: XmlHelper and ContentRepositoryAuthorFacetSearchTestsThe functionality in this trait is unit tested where it is mixed in
  • This really does not need to be a trait. The elements could be mixed in easily from an object;can just explain what a scala object is here I think
  • The package objects are a language feature that I’d say Is not understood well. -> Your blog post?
  • The trait has a declares a structural self typeThis is confusing for people
  • Only Language andWebdriverDon’t actually need to pass in as long as it’s in the context
  • The expilictly defined implicit
  • HttpSupportPeople find implicits really hard to understand and to keep that understanding in their minds
  • Keep it as Option as long as possible until you actually want to do something with it
  • The mental model seems to be getting harder to understandThere was a SeriesBuilder and a BookSeriesBuilder – building the same bit of xml. Is it difficult to work out where things are? Have we been lured into throwing away good principles and practices by a new shiny languageHow significant is the test coverage? Tool supportRefactoring
  • Us and the project
  • Should It have been written in java? We did a code retrospective on this in September
  • JUNE:+++ Increased developer productivity • Higher-level language constructs (functional programming, actors, pattern matching, mixins, etc.) • Less code -> less time spent reading code / less defects • Syntax is better suited for writing DSLs (e.g. SBT, Scalatra, ScalaTest, etc.)+++ Bigger potential to attract talented developers++ Gentle learning curve for Java devs+ Built-in support at language-level for handling XML+ Comes with SBT, a powerful build tool+ Seamlessly integrates with Java and it's ecosystem+ Runs on the JVM (i.e. no operational concerns)--- Bigger potential to screw things up (think: "with great power comes...")-- Tool support is less mature and polished (e.g. IDEs, profilers, metrics, etc.)- Community is younger and smaller- Scala compiler seems to be slower than Java counterparts
  • SEPTEMBERIn our code review at the beginning of September we discussed what features we liked, disliked and were unsure about. The outcome was as follows:Liked:+8 Easy to learn+8 Functional Language (Immutables, closures, etc)+6 Consise code+5 SBT power+4 Case classes+4 XML support+4 Java integration+3 List processing+3 DSL support+2 Helpful community (IRC, Stackoverflow)+2 PerformanceDisliked:-8 IDE support (refactoring, plugin quality)-5 Slow compiler-3 Code can become complex to read-2 Lack of XPath support in XML-2 SBT complexity-2 Immature frameworks
  • Not in here yet: Odersky maturity modelSpiewak coding standardsExpliticly mention that it gets more complex for new people to understand?
  • Scala: An experience report

    1. 1. Scala Experience ReportMark Needham and Liz Douglass
    2. 2. Funny image?
    3. 3. Funny image?
    4. 4. Does it really speed up the development as was hoped?Should the projecthave been done in Java? Is it easier to maintain and extend than an equivalent Java code What features of the base? language and patterns of usage have been successes?
    5. 5. TestingTemplating Domain
    6. 6. Testing
    7. 7. scalatest
    8. 8. Unit testing
    9. 9. Functional Testing
    10. 10. Test DSL
    11. 11. First class functions
    12. 12. Test DSL
    13. 13. # of unit tests: 449# of integration tests: 280# of functional tests: 353
    14. 14. Unit testing
    15. 15. Unit testing
    16. 16. Unit testing
    17. 17. Templating
    18. 18. Scalatra
    19. 19. Scalatra Scalate
    20. 20. SSP scamlScalatra Scalate jade Mustache
    21. 21. Controller
    22. 22. Mustache
    23. 23. Jade
    24. 24. View Helper
    25. 25. Jade
    26. 26. Domain
    27. 27. Presentation Model
    28. 28. XML
    29. 29. More XML
    30. 30. More XML
    31. 31. And not just XML…
    32. 32. Going too far!
    33. 33. TraitsWhich example was this supposed to be?ContentRepository - JUNE
    34. 34. Traits1. Utilities
    35. 35. Traits2. Presentation Model
    36. 36. Traits3. Helpers to Helpers
    37. 37. Traits4. Wanna be objects
    38. 38. Traits5. Type container
    39. 39. Traits6. Traits with standards
    40. 40. Implicits
    41. 41. Implicits
    42. 42. Implicits
    43. 43. Options
    44. 44. Tendency to have fewer testsRefactoring Code discoverability
    45. 45. In Retrospect …
    46. 46. Does it really speed up the development as was hoped?Should the projecthave been done in Java? Is it easier to maintain and extend than an equivalent Java code What features of the base? language and patterns of usage have been successes?
    47. 47. Scala compiler slower than Java’s
    48. 48. Questions