Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (19)
Similar a Scala: An experience report
Similar a Scala: An experience report (20)
Más de Mark Needham
Más de Mark Needham (14)
Último
Último (20)
Scala: An experience report
- 1. Scala Experience Report Mark Needham and Liz Douglass
- 2. Funny image?
- 3. Funny image?
- 4. Does it really speed up the development as was hoped? Should the project have 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?
- 7. Testing
- 8. scalatest
- 9. Unit testing
- 11. Test DSL
- 13. Test DSL
- 14. # of unit tests: 449 # of integration tests: 280 # of functional tests: 353
- 15. Unit testing
- 16. Unit testing
- 17. Unit testing
- 18. Templating
- 19. Scalatra
- 20. Scalatra Scalate
- 21. SSP scaml Scalatra Scalate jade Mustache
- 22. Controller
- 23. Mustache
- 24. Jade
- 25. View Helper
- 26. Jade
- 27. Domain
- 29. XML
- 30. More XML
- 31. More XML
- 32. And not just XML…
- 33. Going too far!
- 34. Traits Which example was this supposed to be? ContentRepository - JUNE
- 37. Traits 3. Helpers to Helpers
- 38. Traits 4. Wanna be objects
- 40. Traits 6. Traits with standards
- 41. Implicits
- 42. Implicits
- 43. Implicits
- 44. Options
- 45. Tendency to have fewer tests Refactoring Code discoverability
- 46. In Retrospect …
- 47. Does it really speed up the development as was hoped? Should the project have 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?
- 49. Scala compiler slower than Java’s
- 51. Questions
Notas del editor
- 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.” (http://blog.schauderhaft.de/2011/08/21/usage-patterns-of-scala-traits/)
- 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? (http://blog.schauderhaft.de/2011/08/21/usage-patterns-of-scala-traits/) : “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?