Wrong confirmation ID

Email
Favorite
Favorited ×
Download
Embed
Private Content
Copy and paste this code into your blog or website Copy Customize… Close
We have emailed the verification/download link to "".
Login to your email and click the link to download the file directly.

To request the link at a different email address, update it here. Close
Validation messages. Success message. Fail message.

Check your bulk/spam folders if you can't find our mail.

Tweet

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Scala: An experience report

by Mark Needham on Nov 24, 2011

2,463 views

An experience report after using scala for 6 months.

An experience report after using scala for 6 months.

Accessibility

View text version

Categories

Technology

Tags

Upload Details

Uploaded via SlideShare as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

File a copyright complaint

9 Embeds 1,718

http://www.markhneedham.com	1102
http://www.thoughtworks.com	440
http://blogs.thoughtworks.com	163
http://feeds2.feedburner.com	6
http://www.hanrss.com	2
http://feeds.feedburner.com	2
http://127.0.0.1:8795	1
http://translate.googleusercontent.com	1
http://webcache.googleusercontent.com	1

Statistics

Favorites: 1
Downloads: 23
Comments: 0
Embed Views: 1,718
Views on SlideShare: 745
Total Views: 2,463

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?

1 Favorite

Stefan Sieber at Zühlke 6 months ago

Scala: An experience report — Presentation Transcript

Scala Experience ReportMark Needham and Liz Douglass
Funny image?
Funny image?
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?
TestingTemplating Domain
Testing
scalatest
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
Templating
Scalatra
Scalatra Scalate
SSP scamlScalatra Scalate jade Mustache
Controller
Mustache
Jade
View Helper
Jade
Domain
Presentation Model
XML
More XML
More XML
And not just XML…
Going too far!
TraitsWhich example was this supposed to be?ContentRepository - JUNE
Traits1. Utilitieshttp://blog.schauderhaft.de/2011/08/21/usage-patterns-of-scala-traits/
Traits2. Presentation Model
Traits3. Helpers to Helpers
Traits4. Wanna be objects
Traits5. Type container
Traits6. Traits with standards
Implicits
Implicits
Implicits
Options
Tendency to have fewer testsRefactoring Code discoverability
In Retrospect …
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?
Scala compiler slower than Java’s
Questions