Posts Tagged ‘Scala’
[DevoxxFR2013] Live Coding: A WOA Application in 50 Minutes
Lecturer
Guillaume Bort co-founded Zenexity, specializing in Web Oriented Architecture. Previously a J2EE expert, he developed web frameworks for large enterprises, creating Play Framework to prioritize simplicity. He leads Play’s development.
Sadek Drobi, Zenexity’s CTO, focuses on enterprise applications, bridging problem and solution domains. As a programming languages expert, he contributes to Play Framework’s core team.
Abstract
Guillaume Bort and Sadek Drobi’s live coding demonstrates building a Web Oriented Architecture (WOA) application using Play Framework and Scala. Consuming Twitter’s API, they handle JSON, integrate MongoDB, and stream real-time data via Server-Sent Events to an HTML5 interface. The session analyzes reactive programming, asynchronous handling, and scalability, showcasing Play’s efficiency for modern web apps.
Setting Up the Foundation: Play Framework and Twitter API Integration
Bort and Drobi initiate with Play Framework, creating a project via activator. They configure routes for homepage and stream endpoints, using Scala’s async for non-blocking I/O.
Consuming Twitter’s search API: construct URLs with keywords like “DevoxxFR”, include entities for images. Use WS (WebService) for HTTP requests, parsing JSON responses.
They extract tweet data: user, text, images. Handle pagination with since_id for subsequent queries, building a stream of results.
This setup leverages Play’s stateless design, ideal for scalability.
Building Reactive Streams: Enumerators and Asynchronous Processing
To create a continuous stream, they employ Enumerators and Iteratees. Poll Twitter periodically (e.g., every 5 seconds), yielding new tweets.
Code uses concurrent scheduling:
val tweets: Enumerator[Tweet] = Enumerator.generateM {
Future {
// Fetch and parse tweets
Some(newTweets)
}
}
Flatten to a single stream. Handle errors with recover, ensuring resilience.
This reactive approach processes data as it arrives, avoiding blocking and enabling real-time updates.
Persisting Data: Integrating MongoDB with ReactiveMongo
For storage, integrate ReactiveMongo: asynchronous, non-blocking driver. Define Tweet case class, insert via JSONCollection.
val collection = db.collection[JSONCollection]("tweets")
collection.insert(tweetJson)
Query for latest since_id. Use find with sort/take for efficient retrieval.
This maintains asynchrony, aligning with WOA’s distributed nature.
Streaming to Clients: Server-Sent Events and HTML5 Interface
Output as EventSource: chunked response with JSON events.
Ok.chunked(tweets &> EventSource()).as("text/event-stream")
Client-side: JavaScript EventSource listens, appending images with animations.
Handle dynamics: form submission triggers stream, updating UI.
This enables push updates, enhancing interactivity without WebSockets.
Optimizing for Scalability: Backpressure and Error Handling
Address overload: use onBackpressureBuffer to queue, drop, or fail. Custom strategies compress or ignore excess.
Play’s Akka integration aids actor-based concurrency.
Implications: Builds resilient, scalable apps handling high loads gracefully.
Collaborative Development: Live Insights and Community Resources
Session highlights rapid prototyping: zero slides, GitHub commits for following.
Drobi comments on concepts like futures unification in Scala 2.10, inter-library interoperability.
They encourage exploring Play docs, plugins for extensions.
This methodology fosters understanding of reactive paradigms, preparing for distributed systems.
Links:
[DevoxxFR2013] FLATMAP ZAT SHIT: Monads Explained to Geeks
Lecturer
François Sarradin is a Java and lambda developer, serving as a technical capitalization manager. He contributes to the Brown Bag Lunch initiative, sharing expertise through presentations.
Abstract
François Sarradin’s session introduces monads in functional programming, using Scala and Java 8 examples to demystify their utility. He addresses handling errors, asynchrony, and technical concerns without cluttering business logic, employing monadic structures like Try and Future. The talk analyzes code transformations for cleaner, composable designs, highlighting monads’ role in aspect-oriented programming and drawing parallels to AOP frameworks.
The Problem: Technical Debt Obscuring Business Logic
Sarradin illustrates a common plight: initial clean code accumulates technical safeguards—null checks, try-catch blocks, synchronization—eroding readability and productivity. He proposes separating concerns: keep business logic pure, inject technical aspects via mechanisms akin to aspect-oriented programming (AOP).
Using AOP tools like AspectJ or Spring AOP declares cross-cutting concerns (e.g., logging, error handling) separately, leveraging compilers for coherence. This maintains original code structure while addressing realities like exceptions or async calls.
An example application in Scala computes total balance across bank accounts, initially straightforward but vulnerable. Technical intrusions (e.g., if-null, try-catch) bloat it, prompting a search for elegant solutions.
Introducing Monads: Error Handling with Try
To manage errors without pervasive checks, Sarradin introduces the Try monad in Scala: a container wrapping success (Success(value)) or failure (Failure(exception)). This allows chaining operations via flatMap and map, propagating errors implicitly.
Transforming the balance app: wrap account retrieval in Try, use for-comprehensions (sugaring flatMap/map) for composition. If any step fails, the whole computation fails gracefully, without explicit exception handling.
Code evolves from imperative checks to declarative chains:
val total = for {
account1 <- Try(getAccount(bank1))
account2 <- Try(getAccount(bank2))
balance1 <- Try(getBalance(account1))
balance2 <- Try(getBalance(account2))
} yield balance1 + balance2
This yields Try[Double], inspectable via isSuccess, get, or getOrElse. Monads here abstract error propagation, enhancing modularity.
Java 8’s Optional partially mirrors this but lacks full monadic power; Sarradin implements a custom Try for illustration, using abstract classes with Success/Failure subclasses.
Extending to Asynchrony: Futures for Non-Blocking Computations
Asynchrony poses similar issues: callbacks or blocking awaits disrupt flow. Scala’s Future monad encapsulates eventual values, enabling composition without blocking.
In the app, wrap async calls in Future: use flatMap to chain, ensuring non-blocking execution. For-comprehensions again simplify:
val totalFuture = for {
account1 <- Future(getAccountAsync(bank1))
account2 <- Future(getAccountAsync(bank2))
balance1 <- Future(getBalanceAsync(account1))
balance2 <- Future(getBalanceAsync(account2))
} yield balance1 + balance2
totalFuture completes asynchronously; callbacks via onComplete handle results. This maintains sequential appearance while parallelizing under the hood.
Sarradin contrasts with Java 8’s CompletableFuture, which offers thenApply/thenCompose for similar chaining, though less idiomatic without for-comprehensions.
Monads as a Unifying Abstraction: Synthesis and Implications
Monads generalize: a type M[A] with map (transform value) and flatMap (chain computations). They inject contexts (error, future) into pure functions, separating concerns.
In the app, combining Try and Future (via Scalaz’s EitherT or custom) handles both errors and asynchrony. This AOP-like injection leverages type systems for safety, contrasting annotation-based AOP.
Java 8 approximates with lambdas and CompletableFuture/Optional, but lacks Scala’s expressiveness. Custom implementations reveal monads’ essence: abstract class with map/flatMap, subclasses for Success/Failure.
Sarradin concludes monads enhance composability, reducing boilerplate for robust, maintainable code in functional paradigms.
Relevant Links and Hashtags
Links:
[DevoxxFR2013] Objects and Functions: Conflict Without a Cause?
Lecturer
Martin Odersky is a professor at EPFL in Lausanne, Switzerland, specializing in programming languages that blend object-oriented and functional paradigms. His research unifies these approaches, evidenced by designs like Pizza, GJ, and Functional Nets. He co-designed Java generics and authored the original javac compiler. Currently, he focuses on Scala, fusing functional and object-oriented programming while ensuring interoperability with Java and .NET.
Abstract
Martin Odersky’s lecture traces object-oriented programming’s (OOP) rise, parallels it with functional programming’s (FP) resurgence, and argues for their synthesis. Analyzing historical catalysts, methodological benefits, and modern hardware demands, he demonstrates how FP addresses parallelism and reactivity challenges. Through Scala examples, Odersky shows OOP and FP as complementary, enhancing modularity and abstraction without mutual exclusion.
Historical Roots and Catalysts for OOP Adoption
Odersky recounts his journey from Pascal compilers to modular languages, Java involvement, and Scala creation. OOP’s mainstreaming, he argues, stemmed not from encapsulation or reuse but practical necessities. Simula (1967) for simulations and Smalltalk (late 1970s) for GUI widgets inverted traditional data structures: fixed operations, unbounded implementations.
In procedural languages like C, this was cumbersome via function pointers; OOP simplified dynamic binding for unknown implementations. Odersky notes early confusion with Smalltalk, mirroring current FP bewilderment. OOP’s advantages – modeling, dependency inversion – emerged post-adoption, sparked by widget programming appeal.
Functional Programming’s Resurgence and Methodological Strengths
FP offers fewer errors, superior modularity, and productivity via higher abstractions and shorter code. Yet, despite 50-year existence, mainstream adoption lagged. Odersky identifies multicore and cloud computing as catalysts: parallelism for hardware utilization, reactivity for asynchronous events, distribution for delays/failures.
Mutable state exacerbates issues like cache coherence and non-determinism in concurrent environments. Immutable data mitigates races, enabling safe caching. Locks/threads scale poorly; even transactions retain problems. FP’s immutability fosters determinism, crucial for scalable systems.
Addressing Modern Computing Challenges with FP
Odersky outlines a triple challenge: parallel, reactive, distributed programming. Mutable state hinders each; FP excels by avoiding it.
For parallelism, he exemplifies mapping developer names: sequential in Scala, parallel via .par, yielding a parallel collection. Side effects risk chaos due to reordered executions, necessitating functional purity for correctness.
Reactivity example: an online store querying users, orders, products, stock. Synchronous calls block threads on slow services, degrading performance. Asynchronous futures prevent blocking; Scala’s for-comprehensions compose them elegantly, hiding complexity. Refactoring for parallelism pairs futures, executing concurrently.
For-comprehensions translate universally to map, flatMap, filter, allowing library-defined interpretations – sequential or async – without polluting domain logic.
Synthesizing OOP and FP: Beyond False Dichotomies
Communities often view OOP and FP oppositely, but Odersky argues orthogonality. Objects modularize (“what goes where”), providing containers with dynamic binding and inheritance. Essential for large codebases (e.g., million-line Scala systems), they prevent global namespace chaos – a Haskell limitation.
Redefine objects: eliminate mutable state dogma (e.g., immutable java.lang.String), structural equality over identity, focus on behavior. Scala embodies this fusion, modeling algebraic types with objects while importing FP capabilities.
Scala unifies scripting (winning JavaOne Script Bowl) and safe, performant systems (core for Twitter, LinkedIn). Odersky concludes OOP/FP synergy enhances development, urging exploration via Scala Days, courses, and talks.
Relevant Links and Hashtags
Links:
[DevoxxBE2012] Rapid Application Development with Play 2
Peter Hausel, a core team member of the Play Framework and software engineer at Typesafe, demonstrated the efficiencies of Play 2 for swift web development in both Java and Scala. With a background in web technologies and open source, Peter showcased how Play streamlines workflows, emphasizing live coding to illustrate its features.
He initiated by creating a new Java-based application, highlighting Play’s MVC structure: controllers for logic, views for Scala-based templates, and routes for URL mapping. Peter noted that even Java projects use Scala templates, which require minimal learning akin to JSP.
A key advantage is on-the-fly compilation; changes reload automatically without restarts, accelerating iterations. Peter modified a controller and template, refreshing the browser to see instant updates.
Type-safe templates and routes prevent runtime errors, with compile-time checks ensuring correctness. He integrated front-end tools like CoffeeScript, LESS, and Google Closure Compiler, compiling them seamlessly into production assets.
Peter explored asset management, using RequireJS for modular JavaScript, and reverse routing to generate URLs dynamically, avoiding hardcoding.
For production, he packaged the app into a distributable ZIP, running it standalone. He peeked into running applications via REPL for interactive debugging.
Testing was touched upon, with future scaffolding promised to generate tests easily.
Peter’s demo underscored Play’s design for productivity, blending familiarity with powerful abstractions.
Core Structure and Development Workflow
Peter detailed Play’s layout: app folder houses controllers, views, and assets; conf holds configurations and routes. Routes define HTTP methods, paths, and controllers, supporting parameters for dynamic handling.
In live coding, he added a new route and controller method, demonstrating error handling where compilation failures display directly in the browser, guiding fixes.
Templates use Scala syntax for logic, with type safety catching mismatches early. Peter included layouts via @main, composing reusable structures.
Front-End Integration and Asset Handling
Play compiles CoffeeScript and LESS on-the-fly, minifying with Closure for optimization. Peter added a CoffeeScript file, seeing it transform into JavaScript.
RequireJS integration modularizes scripts, with routes serving them efficiently.
Deployment and Advanced Features
Packaging creates self-contained distributions, runnable via commands. REPL allows inspecting live state.
Peter recapped: routes centralize mapping, auto-reload speeds development, and reverse routing enhances maintainability.
His session positioned Play as a tool for rapid, robust applications.