This document provides an overview of Scalaz and functional programming concepts like Functor, Applicative, and Monad as they relate to the Option type in Scalaz. It discusses Option syntax, constructing Options, working with Options using fold, map, and other methods, and defines Option as an instance of Functor, Applicative, and Monoid. It also briefly touches on concepts like context bounds and alternative monoids for Option.
Introduces the functional programming ideas of Functor, Apply, Applicative And Monad. Shows how to implement each in Scala with Scalaz and how to validate the implementation using property based test using specs2 and scalacheck.
Some languages, like SML, Haskell, and Scala, have built-in support for pattern matching, which is a generic way of branching based on the structure of data.
While not without its drawbacks, pattern matching can help eliminate a lot of boilerplate, and it's often cited as a reason why functional programming languages are so concise.
In this talk, John A. De Goes talks about the differences between built-in patterns, and so-called first-class patterns (which are "do-it-yourself" patterns implemented using other language features).
Unlike built-in patterns, first-class patterns aren't magical, so you can store them in variables and combine them in lots of interesting ways that aren't always possible with built-in patterns. In addition, almost every programming language can support first-class patterns (albeit with differing levels of effort and type-safety).
During the talk, you'll watch as a mini-pattern matching library is developed, and have the opportunity to follow along and build your own pattern matching library in the language of your choice.
Scalaz 8 is the latest edition of the popular functional programming library for Scala. In this whirlwind tour, maintainer John A. De Goes discusses some of the hottest features of Scalaz 8, including all of the following:
* A fast, concurrent, and leak-free effect system, which has small, composable, and powerful primitives for building practical, real-world software;
* A non-linear type class hierarchy, which permits a more powerful hierarchy that infers well without devastating ambiguous implicit errors;
* A new encoding for abstractions in category theory that providers higher fidelity and enables new categories of useful software to be developed;
* A Scala 2.12 encoding of opaque types that powers improved performance and better developer UX.
In this tour, you’ll see how the design of Scalaz 8 was inspired by a desire to provide Scala developers with a principled, performant, and pragmatic library that never sacrifices the safety and equational reasoning properties of functional programming. You’ll see live code snippets that show you how solving complex real world problems is simpler, faster, safer, and more reasonable than in previous versions of Scalaz. And hopefully you’ll be inspired at just how far functional programming in Scala has come in the past decade.
Introduces the functional programming ideas of Functor, Apply, Applicative And Monad. Shows how to implement each in Scala with Scalaz and how to validate the implementation using property based test using specs2 and scalacheck.
Some languages, like SML, Haskell, and Scala, have built-in support for pattern matching, which is a generic way of branching based on the structure of data.
While not without its drawbacks, pattern matching can help eliminate a lot of boilerplate, and it's often cited as a reason why functional programming languages are so concise.
In this talk, John A. De Goes talks about the differences between built-in patterns, and so-called first-class patterns (which are "do-it-yourself" patterns implemented using other language features).
Unlike built-in patterns, first-class patterns aren't magical, so you can store them in variables and combine them in lots of interesting ways that aren't always possible with built-in patterns. In addition, almost every programming language can support first-class patterns (albeit with differing levels of effort and type-safety).
During the talk, you'll watch as a mini-pattern matching library is developed, and have the opportunity to follow along and build your own pattern matching library in the language of your choice.
Scalaz 8 is the latest edition of the popular functional programming library for Scala. In this whirlwind tour, maintainer John A. De Goes discusses some of the hottest features of Scalaz 8, including all of the following:
* A fast, concurrent, and leak-free effect system, which has small, composable, and powerful primitives for building practical, real-world software;
* A non-linear type class hierarchy, which permits a more powerful hierarchy that infers well without devastating ambiguous implicit errors;
* A new encoding for abstractions in category theory that providers higher fidelity and enables new categories of useful software to be developed;
* A Scala 2.12 encoding of opaque types that powers improved performance and better developer UX.
In this tour, you’ll see how the design of Scalaz 8 was inspired by a desire to provide Scala developers with a principled, performant, and pragmatic library that never sacrifices the safety and equational reasoning properties of functional programming. You’ll see live code snippets that show you how solving complex real world problems is simpler, faster, safer, and more reasonable than in previous versions of Scalaz. And hopefully you’ll be inspired at just how far functional programming in Scala has come in the past decade.
Final tagless. The topic strikes fear into the hearts of Scala developers everywhere—and not without reason. Final tagless allows developers to build composable Domain Specific Languages (DSLs) that model interaction with the outside world. Programs written using the final tagless style can be tested deterministically and reasoned about at compile-time. Yet the technique requires confusing, compiler-choking higher-kinded types, like `F[_]`, and pervasive, non-inferable context bounds like `F[_]: Concurrent: Console: Logging`. Many have looked at final tagless and wondered if all the layers of complexity and ceremony are really worth the benefits.
In this presentation, John A. De Goes provides a gentle and accessible introduction to final tagless, explaining what it is and the problem it intends to solve. John shows that while final tagless is easier to use than free monads, the technique suffers from a litany of drawbacks that push developers away from functional programming in Scala. John then introduces a novel approach that shares some of the benefits of final tagless, but which is idiomatic Scala, easy to explain, doesn’t need any complex type machinery, provides flawless type inference, and works beautifully across Scala 2.x and Scala 3.
Come join John for an evening of fun as you learn how to write functional code in Scala that's easy to test and easy to reason about—all without the complexity of free monads or final tagless.
"The joy of Scala" - Maxim Novak / Wix
Around eight years ago I started my journey as a developer. Since then, I've played around with many languages and thought that C# offers the best developer productivity. After joining Wix two years ago, I was exposed to the amazing world of Scala and Functional Programming and never looked back.
In Scala the code is much more concise, less ceremonious, immutable by default, combines functional with object oriented, seamlessly interoperates with Java, and many software engineering patterns are already baked into the language. Most importantly - Scala is FUN! By the end of the session you too will, hopefully, convert to Scala and never look back.
Recording of the lecture (Hebrew) - https://youtu.be/TcnYTwff2xU
The Design of the Scalaz 8 Effect SystemJohn De Goes
Purely functional Scala code needs something like Haskell's IO monad—a construct that allows functional programs to interact with external, effectful systems in a referentially transparent way. To date, most effect systems for Scala have fallen into one of two categories: pure, but slow or inexpressive; or fast and expressive, but impure and unprincipled. In this talk, John A. De Goes, the architect of Scalaz 8’s new effect system, introduces a novel solution that’s up to 100x faster than Future and Cats Effect, in a principled, modular design that ships with all the powerful primitives necessary for building complex, real-world, high-performance, concurrent functional programs.
Thanks to built-in concurrency, high performance, lawful semantics, and rich expressivity, Scalaz 8's effect system may just be the effect system to attract the mainstream Scala developers who aren't familiar with functional programming.
Quark: A Purely-Functional Scala DSL for Data Processing & AnalyticsJohn De Goes
Quark is a new Scala DSL for data processing and analytics that runs on top of the Quasar Analytics compiler. Quark is adept at processing semi-structured data and compiles query plans to operations that run entirely inside a target data source. In this presentation, John A. De Goes provides an overview of the open source library, showing several use cases in data processing and analytics. John also demonstrates a powerful technique that every developer can use to create their own purely-functional, type-safe DSLs in the Scala programming language.
For decades, the Functor, Monoid, and Foldable type class hierarchies have dominated functional programming. Implemented in libraries like Scalaz and Cats, these type classes have an ancient origin in Haskell, and they have repeatedly proven useful for advanced functional programmers, who use them to maximize code reuse and increase code correctness.
Yet, as these type classes have been copied into Scala and aged, there is a growing awareness of their drawbacks, ranging from being difficult to teach to weird operators that don’t make sense in Scala (ap from Applicative), to overlapping and lawless type classes (Semigroupal), to a complete inability to abstract over data types that possess related structure (such as isomorphic applicatives).
In this presentation, John A. De Goes introduces a new Scala library with a completely different factoring of functional type classes—one which throws literally everything away and starts from a clean slate. In this new factoring, type classes leverage Scala’s strengths, including variance and modularity. Pieces fit together cleanly and uniformly, and in a way that satisfies existing use cases, but enables new ones never before possible. Finally, type classes are named, organized, and described in a way that makes teaching them easier, without compromising on algebraic principles.
If you’ve ever thought functional type classes were too impractical or too confusing or too restrictive, now’s your chance to get a fresh perspective on a library that just might make understanding functional programming easier than ever before!
This is going to be a discussion about design patterns. But I promise it’s going to be very different from the Gang of Four patterns that we all have used and loved in Java.
It doesn’t have any mathematics or category theory - it’s about developing an insight that lets u identify code structures that u think may be improved with a beautiful transformation of an algebraic pattern.
In earlier days of Java coding we used to feel proud when we could locate a piece of code that could be transformed into an abstract factory and the factory bean could be injected using Spring DI. The result was we ended up maintaining not only Java code, but quite a bit of XML too, untyped and unsafe. This was the DI pattern in full glory. In this session we will discuss patterns that don’t look like external artifacts, they are part of the language, they have some mathematical foundations in the sense that they have an algebra that actually compose and compose organically to evolve larger abstractions.
Free monads and free applicatives have proven an incredibly useful tool in repertoire of the functional programmer: they separate concerns, encourage denotational semantics for program specification, allow easy and type-safe mocking of purely functional code, and allow dynamic introspection and optimization.
Despite these benefits, free monads are notoriously constrained: by themselves, they cannot handle parallelism (only sequentiality), and because they provide only a monad, richer structures (such as monads that fail, or monads that support alternation) cannot be expressed without crude hacks that limit composability and expressiveness.
In this session, John A. De Goes shows how the free monad can be deconstructed for its individual features, and then rebuilt using a more powerful technique that enables more extensibility. The resulting structure — no longer technically a "free monad" — allows reification of as few or as many aspects of computation as are necessary to model the problem domain.
After the session, attendees will know how to augment their existing free programs to add parallelism, racing, failure, and other aspects of computation as required by their problem. In addition, through this thorough deconstruction and reconstruction of the free monad, attendees will have a very deep understanding of reified computation and why the free monad has the structure and limitations it does.
Short (45 min) version of my 'Pragmatic Real-World Scala' talk. Discussing patterns and idioms discovered during 1.5 years of building a production system for finance; portfolio management and simulation.
Some parts of our applications don't need to be asynchronous or interact with the outside world: it's enough that they are stateful, possibly with the ability to handle failure, context, and logging. Although you can use ZIO 2 or monad transformers for this task, both come with drawbacks. In this presentation, Jorge Vásquez will introduce you to ZPure, a data type from ZIO Prelude, which lets you scale back on the power of ZIO 2, but with the same high-performance, type-inference, and ergonomics you expect from ZIO 2 libraries.
Blazing Fast, Pure Effects without Monads — LambdaConf 2018John De Goes
Effect monads like IO are the way functional programmers interact with the real world. Yet, monadic effects in programming languages like Scala often perform poorly compared to their Haskell counterparts—as much as 10x slower in some benchmarks. In this presentation, John A. De Goes, author of the Scalaz 8 effect system, dredges up an old paper to cast new light on the question of how to model effects, and comes to the surprising conclusion that in Scala, monads may not be the fastest way to model purely functional effects. Join John as he shows a new model of effects that offers performance improvements without sacrificing the wonderful purity that functional programmers rely on to reason about their software.
(Video of these slides here http://fsharpforfunandprofit.com/rop)
(My response to "this is just Either" here: http://fsharpforfunandprofit.com/rop/#monads)
Many examples in functional programming assume that you are always on the "happy path". But to create a robust real world application you must deal with validation, logging, network and service errors, and other annoyances.
So, how do you handle all this in a clean functional way? This talk will provide a brief introduction to this topic, using a fun and easy-to-understand railway analogy.
Final tagless. The topic strikes fear into the hearts of Scala developers everywhere—and not without reason. Final tagless allows developers to build composable Domain Specific Languages (DSLs) that model interaction with the outside world. Programs written using the final tagless style can be tested deterministically and reasoned about at compile-time. Yet the technique requires confusing, compiler-choking higher-kinded types, like `F[_]`, and pervasive, non-inferable context bounds like `F[_]: Concurrent: Console: Logging`. Many have looked at final tagless and wondered if all the layers of complexity and ceremony are really worth the benefits.
In this presentation, John A. De Goes provides a gentle and accessible introduction to final tagless, explaining what it is and the problem it intends to solve. John shows that while final tagless is easier to use than free monads, the technique suffers from a litany of drawbacks that push developers away from functional programming in Scala. John then introduces a novel approach that shares some of the benefits of final tagless, but which is idiomatic Scala, easy to explain, doesn’t need any complex type machinery, provides flawless type inference, and works beautifully across Scala 2.x and Scala 3.
Come join John for an evening of fun as you learn how to write functional code in Scala that's easy to test and easy to reason about—all without the complexity of free monads or final tagless.
"The joy of Scala" - Maxim Novak / Wix
Around eight years ago I started my journey as a developer. Since then, I've played around with many languages and thought that C# offers the best developer productivity. After joining Wix two years ago, I was exposed to the amazing world of Scala and Functional Programming and never looked back.
In Scala the code is much more concise, less ceremonious, immutable by default, combines functional with object oriented, seamlessly interoperates with Java, and many software engineering patterns are already baked into the language. Most importantly - Scala is FUN! By the end of the session you too will, hopefully, convert to Scala and never look back.
Recording of the lecture (Hebrew) - https://youtu.be/TcnYTwff2xU
The Design of the Scalaz 8 Effect SystemJohn De Goes
Purely functional Scala code needs something like Haskell's IO monad—a construct that allows functional programs to interact with external, effectful systems in a referentially transparent way. To date, most effect systems for Scala have fallen into one of two categories: pure, but slow or inexpressive; or fast and expressive, but impure and unprincipled. In this talk, John A. De Goes, the architect of Scalaz 8’s new effect system, introduces a novel solution that’s up to 100x faster than Future and Cats Effect, in a principled, modular design that ships with all the powerful primitives necessary for building complex, real-world, high-performance, concurrent functional programs.
Thanks to built-in concurrency, high performance, lawful semantics, and rich expressivity, Scalaz 8's effect system may just be the effect system to attract the mainstream Scala developers who aren't familiar with functional programming.
Quark: A Purely-Functional Scala DSL for Data Processing & AnalyticsJohn De Goes
Quark is a new Scala DSL for data processing and analytics that runs on top of the Quasar Analytics compiler. Quark is adept at processing semi-structured data and compiles query plans to operations that run entirely inside a target data source. In this presentation, John A. De Goes provides an overview of the open source library, showing several use cases in data processing and analytics. John also demonstrates a powerful technique that every developer can use to create their own purely-functional, type-safe DSLs in the Scala programming language.
For decades, the Functor, Monoid, and Foldable type class hierarchies have dominated functional programming. Implemented in libraries like Scalaz and Cats, these type classes have an ancient origin in Haskell, and they have repeatedly proven useful for advanced functional programmers, who use them to maximize code reuse and increase code correctness.
Yet, as these type classes have been copied into Scala and aged, there is a growing awareness of their drawbacks, ranging from being difficult to teach to weird operators that don’t make sense in Scala (ap from Applicative), to overlapping and lawless type classes (Semigroupal), to a complete inability to abstract over data types that possess related structure (such as isomorphic applicatives).
In this presentation, John A. De Goes introduces a new Scala library with a completely different factoring of functional type classes—one which throws literally everything away and starts from a clean slate. In this new factoring, type classes leverage Scala’s strengths, including variance and modularity. Pieces fit together cleanly and uniformly, and in a way that satisfies existing use cases, but enables new ones never before possible. Finally, type classes are named, organized, and described in a way that makes teaching them easier, without compromising on algebraic principles.
If you’ve ever thought functional type classes were too impractical or too confusing or too restrictive, now’s your chance to get a fresh perspective on a library that just might make understanding functional programming easier than ever before!
This is going to be a discussion about design patterns. But I promise it’s going to be very different from the Gang of Four patterns that we all have used and loved in Java.
It doesn’t have any mathematics or category theory - it’s about developing an insight that lets u identify code structures that u think may be improved with a beautiful transformation of an algebraic pattern.
In earlier days of Java coding we used to feel proud when we could locate a piece of code that could be transformed into an abstract factory and the factory bean could be injected using Spring DI. The result was we ended up maintaining not only Java code, but quite a bit of XML too, untyped and unsafe. This was the DI pattern in full glory. In this session we will discuss patterns that don’t look like external artifacts, they are part of the language, they have some mathematical foundations in the sense that they have an algebra that actually compose and compose organically to evolve larger abstractions.
Free monads and free applicatives have proven an incredibly useful tool in repertoire of the functional programmer: they separate concerns, encourage denotational semantics for program specification, allow easy and type-safe mocking of purely functional code, and allow dynamic introspection and optimization.
Despite these benefits, free monads are notoriously constrained: by themselves, they cannot handle parallelism (only sequentiality), and because they provide only a monad, richer structures (such as monads that fail, or monads that support alternation) cannot be expressed without crude hacks that limit composability and expressiveness.
In this session, John A. De Goes shows how the free monad can be deconstructed for its individual features, and then rebuilt using a more powerful technique that enables more extensibility. The resulting structure — no longer technically a "free monad" — allows reification of as few or as many aspects of computation as are necessary to model the problem domain.
After the session, attendees will know how to augment their existing free programs to add parallelism, racing, failure, and other aspects of computation as required by their problem. In addition, through this thorough deconstruction and reconstruction of the free monad, attendees will have a very deep understanding of reified computation and why the free monad has the structure and limitations it does.
Short (45 min) version of my 'Pragmatic Real-World Scala' talk. Discussing patterns and idioms discovered during 1.5 years of building a production system for finance; portfolio management and simulation.
Some parts of our applications don't need to be asynchronous or interact with the outside world: it's enough that they are stateful, possibly with the ability to handle failure, context, and logging. Although you can use ZIO 2 or monad transformers for this task, both come with drawbacks. In this presentation, Jorge Vásquez will introduce you to ZPure, a data type from ZIO Prelude, which lets you scale back on the power of ZIO 2, but with the same high-performance, type-inference, and ergonomics you expect from ZIO 2 libraries.
Blazing Fast, Pure Effects without Monads — LambdaConf 2018John De Goes
Effect monads like IO are the way functional programmers interact with the real world. Yet, monadic effects in programming languages like Scala often perform poorly compared to their Haskell counterparts—as much as 10x slower in some benchmarks. In this presentation, John A. De Goes, author of the Scalaz 8 effect system, dredges up an old paper to cast new light on the question of how to model effects, and comes to the surprising conclusion that in Scala, monads may not be the fastest way to model purely functional effects. Join John as he shows a new model of effects that offers performance improvements without sacrificing the wonderful purity that functional programmers rely on to reason about their software.
(Video of these slides here http://fsharpforfunandprofit.com/rop)
(My response to "this is just Either" here: http://fsharpforfunandprofit.com/rop/#monads)
Many examples in functional programming assume that you are always on the "happy path". But to create a robust real world application you must deal with validation, logging, network and service errors, and other annoyances.
So, how do you handle all this in a clean functional way? This talk will provide a brief introduction to this topic, using a fun and easy-to-understand railway analogy.
The state of sbt 0.13, sbt server, and sbt 1.0 (ScalaSphere ver)Eugene Yokota
Talk given at ScalaSphere 2017. A review of:
- the sbt 0.13.x series that’s been under development as a technology preview since 2014
- the sbt server feature which is planned to be shipped with the next major sbt release
- and the rest of sbt 1.0
Slides for my recent presentation at the CASE meetup, May 21st. Discusses functional programming features in Scala. Goes from basic FP features like higher-order functions all the way through to monads.
Optics with monocle - Modeling the part and the wholeIlan Godik
Functional Programming is based on the concept of using pure functions, which at first sight limit us from various things as I/O, mutation - change and throwing exceptions - dealing with errors or uncertainty.
Optics help us deal with change inside compound structures and with branches (as with error handling), by providing facilities for looking into complex structures, and modifying a part of them, as well as powerful abstractions for composing optics, in order to build even more complex systems.
In this talk, I will introduce some of the optics, as Lenses, Prisms and Isomorphisms, and the motivation behind them, powerful use cases with Polymorphic Optics in Monocle, and if time will allow, explain the interesting representation of Lenses through Van Laarhoven Lenses.
Lens is an abstraction from functional programming which helps to deal with a problem of updating complex immutable nested objects. This talk contains different usage of Lenses like QuickLens, Sauron, Scalaz.Lens.
Scalaz is a Scala library for functional programming.
It provides purely functional data structures to complement those from the Scala standard library. It defines a set of foundational type classes (e.g. Functor, Monad) and corresponding instances for a large number of data structures.
A dive into akka streams: from the basics to a real-world scenarioGioia Ballin
Reactive streaming is becoming the best approach to handle data flows across asynchronous boundaries. Here, we present the implementation of a real-world application based on Akka Streams. After reviewing the basics, we will discuss the development of a data processing pipeline that collects real-time sensor data and sends it to a Kinesis stream. There are various possible point of failures in this architecture. What should happen when Kinesis is unavailable? If the data flow is not handled in the correct way, some information may get lost. Akka Streams are the tools that enabled us to build a reliable processing logic for the pipeline that avoids data losses and maximizes the robustness of the entire system.
Big data never stops and neither should your Spark jobs. They should not stop when they see invalid input data. They should not stop when there are bugs in your code. They should not stop because of I/O-related problems. They should not stop because the data is too big. Bulletproof jobs not only keep working but they make it easy to identify and address the common problems encountered in large-scale production Spark processing: from data quality to code quality to operational issues to rising data volumes over time.
In this session you will learn three key principles for bulletproofing your Spark jobs, together with the architecture and system patterns that enable them. The first principle is idempotence. Exemplified by Spark 2.0 Idempotent Append operations, it enables 10x easier failure management. The second principle is row-level structured logging. Exemplified by Spark Records, it enables 100x (yes, one hundred times) faster root cause analysis. The third principle is invariant query structure. It is exemplified by Resilient Partitioned Tables, which allow for flexible management of large scale data over long periods of time, including late arrival handling, reprocessing of existing data to deal with bugs or data quality issues, repartitioning already written data, etc.
These patterns have been successfully used in production at Swoop in the demanding world of petabyte-scale online advertising.
My Scala by the Bay 2014 talk on exploring the ideas behind the implementation of the generic library shapeless, and general ideas about how to do "type level" programming in Scala.
Monads and Monoids: from daily java to Big Data analytics in Scala
Finally, after two decades of evolution, Java 8 made a step towards functional programming. What can Java learn from other mature functional languages? How to leverage obscure mathematical abstractions such as Monad or Monoid in practice? Usually people find it scary and difficult to understand. Oleksiy will explain these concepts in simple words to give a feeling of powerful tool applicable in many domains, from daily Java and Scala routines to Big Data analytics with Storm or Hadoop.
A tour of Python: slides from presentation given in 2012.
[Some slides are not properly rendered in SlideShare: the original is still available at http://www.aleksa.org/2015/04/python-presentation_7.html.]
After a recap of implicits I introduce the type class mechanics in Scala. Then I have a look at ways for good non-intrusive type class design. The main focus of this presentation are type classes in Scala. In the last chapter I show the Haskell implementation of my example.
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered QualityInflectra
In this insightful webinar, Inflectra explores how artificial intelligence (AI) is transforming software development and testing. Discover how AI-powered tools are revolutionizing every stage of the software development lifecycle (SDLC), from design and prototyping to testing, deployment, and monitoring.
Learn about:
• The Future of Testing: How AI is shifting testing towards verification, analysis, and higher-level skills, while reducing repetitive tasks.
• Test Automation: How AI-powered test case generation, optimization, and self-healing tests are making testing more efficient and effective.
• Visual Testing: Explore the emerging capabilities of AI in visual testing and how it's set to revolutionize UI verification.
• Inflectra's AI Solutions: See demonstrations of Inflectra's cutting-edge AI tools like the ChatGPT plugin and Azure Open AI platform, designed to streamline your testing process.
Whether you're a developer, tester, or QA professional, this webinar will give you valuable insights into how AI is shaping the future of software delivery.
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
"Impact of front-end architecture on development cost", Viktor TurskyiFwdays
I have heard many times that architecture is not important for the front-end. Also, many times I have seen how developers implement features on the front-end just following the standard rules for a framework and think that this is enough to successfully launch the project, and then the project fails. How to prevent this and what approach to choose? I have launched dozens of complex projects and during the talk we will analyze which approaches have worked for me and which have not.
State of ICS and IoT Cyber Threat Landscape Report 2024 previewPrayukth K V
The IoT and OT threat landscape report has been prepared by the Threat Research Team at Sectrio using data from Sectrio, cyber threat intelligence farming facilities spread across over 85 cities around the world. In addition, Sectrio also runs AI-based advanced threat and payload engagement facilities that serve as sinks to attract and engage sophisticated threat actors, and newer malware including new variants and latent threats that are at an earlier stage of development.
The latest edition of the OT/ICS and IoT security Threat Landscape Report 2024 also covers:
State of global ICS asset and network exposure
Sectoral targets and attacks as well as the cost of ransom
Global APT activity, AI usage, actor and tactic profiles, and implications
Rise in volumes of AI-powered cyberattacks
Major cyber events in 2024
Malware and malicious payload trends
Cyberattack types and targets
Vulnerability exploit attempts on CVEs
Attacks on counties – USA
Expansion of bot farms – how, where, and why
In-depth analysis of the cyber threat landscape across North America, South America, Europe, APAC, and the Middle East
Why are attacks on smart factories rising?
Cyber risk predictions
Axis of attacks – Europe
Systemic attacks in the Middle East
Download the full report from here:
https://sectrio.com/resources/ot-threat-landscape-reports/sectrio-releases-ot-ics-and-iot-security-threat-landscape-report-2024/
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...Jeffrey Haguewood
Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows.
We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases.
This video focuses on the notifications, alerts, and approval requests using Slack for Bonterra Impact Management. The solutions covered in this webinar can also be deployed for Microsoft Teams.
Interested in deploying notification automations for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
19. Option unary ~
Alias for getOrElse(zero)
import scalaz.std.anyVal._
import scalaz.std.option._
import scalaz.syntax.std.option._
def zget(opt: Option[Int]) = ~opt
zget(Some(42)) 42
zget(None) 0
Where does zero come from?
22. Aside: Context Bounds
def mzget[A : Monoid](opt: Option[A]) = ~opt
• Monoid is a context bound for type A
23. Aside: Context Bounds
def mzget[A : Monoid](opt: Option[A]) = ~opt
• Monoid is a context bound for type A
• Means there must be an implicit value of type
Monoid[A] in implicit scope
24. Aside: Context Bounds
def mzget[A : Monoid](opt: Option[A]) = ~opt
• Monoid is a context bound for type A
• Means there must be an implicit value of type
Monoid[A] in implicit scope
• Equivalent to:
def mzget[A](opt: Option[A])(
implicit m: Monoid[A]) = ~opt
25. Aside: Context Bounds
def mzget[A : Monoid](opt: Option[A]) = ~opt
• Monoid is a context bound for type A
• Means there must be an implicit value of type
Monoid[A] in implicit scope
• Equivalent to:
def mzget[A](opt: Option[A])(
implicit m: Monoid[A]) = ~opt
• Even other[A multiple bounds:
def
supports
: Monoid : Functor] = ...
27. Option err
Alias for getOrElse(sys.err(msg))
def knowBetter[A](opt: Option[A]) =
opt err "You promised!"
knowBetter(some(42)) 42
knowBetter(none)
throws RuntimException(“You promised!”)
Good alternative to opt.get when you know it’s defined!
31. Concatenate
Given a list of options, how do you sum them?
List(some(42), none, some(51)).sum
error: could not find implicit value for
parameter num: Numeric[Option[Int]]
32. Concatenate
Given a list of options, how do you sum them?
List(some(42), none, some(51)).sum
error: could not find implicit value for
parameter num: Numeric[Option[Int]]
import scalaz.syntax.traverse._
List(some(42), none, some(51)).concatenate
93
33. Sequence
Given a list of options, how do you get option of list?
List(some(42), none, some(51)).sequence
None
List(some(42), some(51)).sequence
Some(List(42, 51))
34. Semigroup & Monoid Review
Not Scala syntax!
• SemigroupA
append: A A
• Monoid extends Semigroup
zero: A
41. Option alternative monoids
• Can we find other monoids for Option?
• Must implement zero and append
• But remember the monoid laws:
• Closure
• Associativity
• Identity
See: http://en.wikipedia.org/wiki/Monoid
42. Option alternative monoids
• Keep everything the same as semigroup
based monoid but focus on:
case (Some(a1), Some(a2)) =>
• Left
case (Some(a1), Some(a2)) => f1
• Right
case (Some(a1), Some(a2)) => f2
49. What’s this?
• ??? extends Functor
point: A F[A]
???: F[A] F[A B] F[B]
• Read as...
Given a function from A to B in a context F and a
value of A in a context F, produce a value of B in
context F.
50. What’s this?
• ??? extends Functor
point: A F[A]
???: F[A] F[A B] F[B]
• Read as...
Given a function from A to B in a context F and a
value of A in a context F, produce a value of B in
context F.
• Represents function application in a context
51. What’s this?
• ??? extends Functor
point: A F[A]
???: F[A] F[A B] F[B]
• Read as...
Given a function from A to B in a context F and a
value of A in a context F, produce a value of B in
context F.
• Represents function application in a context
• Defined in http://www.soi.city.ac.uk/~ross/papers/Applicative.html
54. Option Is Applicative
Let’s define an applicative instance for Option
implicit val optionInstance = new Applicative[Option] {
override def point[A](a: => A) = ???
override def ap[A, B](
fa: => Option[A])(f: => Option[A => B]) = ???
}
Summarized from Scalaz Seven source
https://github.com/scalaz/scalaz/blob/scalaz-seven/core/src/main/scala/scalaz/Option.scala
55. Option Is Applicative
How can we lift a value of A to Option[A]?
implicit val optionInstance = new Applicative[Option] {
override def point[A](a: => A) = ???
override def ap[A, B](
fa: => Option[A])(f: => Option[A => B]) = ???
}
Summarized from Scalaz Seven source
https://github.com/scalaz/scalaz/blob/scalaz-seven/core/src/main/scala/scalaz/Option.scala
56. Option Is Applicative
implicit val optionInstance = new Applicative[Option] {
override def point[A](a: => A) = Some(a)
override def ap[A, B](
fa: => Option[A])(f: => Option[A => B]) = ???
}
Summarized from Scalaz Seven source
https://github.com/scalaz/scalaz/blob/scalaz-seven/core/src/main/scala/scalaz/Option.scala
57. Option Is Applicative
How can we apply the function in
Option[A=>B] to Option[A]?
implicit val optionInstance = new Applicative[Option] {
override def point[A](a: => A) = Some(a)
override def ap[A, B](
fa: => Option[A])(f: => Option[A => B]) = ???
}
Summarized from Scalaz Seven source
https://github.com/scalaz/scalaz/blob/scalaz-seven/core/src/main/scala/scalaz/Option.scala
58. Option Is Applicative
implicit val optionInstance = new Applicative[Option] {
override def point[A](a: => A) = Some(a)
override def ap[A, B](
fa: => Option[A])(f: => Option[A => B]) = f match {
case Some(f) => fa match {
case Some(x) => Some(f(x))
case None => None
}
case None => None
}
}
Summarized from Scalaz Seven source
https://github.com/scalaz/scalaz/blob/scalaz-seven/core/src/main/scala/scalaz/Option.scala
59. Option Is Applicative
implicit val optionInstance = new Applicative[Option] {
override def point[A](a: => A) = Some(a)
override def ap[A, B](
fa: => Option[A])(f: => Option[A => B]) = f match {
case Some(f) => fa match {
case Some(x) => Some(f(x))
case None => None
}
case None => None
}
}
What about map[A](f: A => B): Option[B]?
Summarized from Scalaz Seven source
https://github.com/scalaz/scalaz/blob/scalaz-seven/core/src/main/scala/scalaz/Option.scala
60. Functor.map on Applicative
Can we define map in terms of pointed and
ap?
trait Applicative[F[_]] extends Functor[F] with Pointed[F] {
def ap[A,B](fa: => F[A])(f: => F[A => B]): F[B]
override def map[A, B](fa: F[A])(f: A => B): F[B] =
???
}
Summarized from Scalaz Seven source
https://github.com/scalaz/scalaz/blob/scalaz-seven/core/src/main/scala/scalaz/Option.scala
61. Functor.map on Applicative
trait Applicative[F[_]] extends Functor[F] with Pointed[F] {
def ap[A,B](fa: => F[A])(f: => F[A => B]): F[B]
override def map[A, B](fa: F[A])(f: A => B): F[B] =
ap(fa)(point(f))
}
Summarized from Scalaz Seven source
https://github.com/scalaz/scalaz/blob/scalaz-seven/core/src/main/scala/scalaz/Option.scala
71. Applicative Builder
Companion has an
apply method
import scalaz.std.option._ automatically created
import scalaz.syntax.applicative._
case class Album(name: String, artist: String)
(some("Wilco") ⊛ some("Sky Blue Sky")) apply Album.apply
72. Applicative Builder
Companion has an
apply method
import scalaz.std.option._ automatically created
import scalaz.syntax.applicative._
case class Album(name: String, artist: String)
(some("Wilco") ⊛ some("Sky Blue Sky")) apply Album.apply
Alias for |@|
73. Applicative Builder
Companion has an
apply method
import scalaz.std.option._ automatically created
import scalaz.syntax.applicative._
case class Album(name: String, artist: String)
(some("Wilco") ⊛ some("Sky Blue Sky")) apply Album.apply
Some(Album(Wilco, Sky Blue Sky))
Alias for |@|
74. Why Applicatives?
• Less restrictive than Monads, and thus,
more general (powerful)
• Composable
http://blog.tmorris.net/monads-do-not-compose/
• Support parallel computation
More on this point later...
75. A word on typeclasses
• So far we’ve seen Semigroup, Monoid, Functor,
Pointed, Applicative, Monad
76. A word on typeclasses
• So far we’ve seen Semigroup, Monoid, Functor,
Pointed, Applicative, Monad
• There are many others -- ApplicativePlus,
MonadPlus, Comonad, Category, Arrow, ArrowPlus,
Foldable, Traversable, Monad Transformers, Reader,
Writer, State, Identity, and more
77. A word on typeclasses
• So far we’ve seen Semigroup, Monoid, Functor,
Pointed, Applicative, Monad
• There are many others -- ApplicativePlus,
MonadPlus, Comonad, Category, Arrow, ArrowPlus,
Foldable, Traversable, Monad Transformers, Reader,
Writer, State, Identity, and more
• These are functional design patterns
• Simpler than most OO design patterns
78. Some Haskell Typeclasses
Credit: Typeclassopedia
http://www.haskell.org/haskellwiki/Typeclassopedia#Introduction
79. Typeclass References
• Haskell Typeclassopedia is a great reference for
learning these
http://www.haskell.org/haskellwiki/Typeclassopedia
• Scala Typeclassopedia describes the big 3 (Functor,
Applicative, Monad)
http://typeclassopedia.bitbucket.org/
80. Validation
sealed trait Validation[+E, +A] {
...
}
final case class Success[E, A](a: A)
extends Validation[E, A]
final case class Failure[E, A](e: E)
extends Validation[E, A]
81. Validation
• Represents either success or failure
• On success, provides the successful value
• On failure, provides the failure value
• Sound familiar?
84. Isomorphic to Either
Validation Either
Success
≅ Right
Failure Left
Q: So why not just use Either?
85. Isomorphic to Either
Validation Either
Success
≅ Right
Failure Left
Q: So why not just use Either?
A: When Validation is constructed with an error type
that has a Semigroup, there exists an Applicative
Functor for Validation that accumulates errors
99. Mapping via Bifunctor
import scalaz.syntax.bifunctor._
Bifunctor = functor of 2 arguments
fromTryCatch("notAnInt".toInt).
<-: { _.getMessage } <-: = Map left value
100. Mapping via Bifunctor
import scalaz.syntax.bifunctor._
Bifunctor = functor of 2 arguments
fromTryCatch("notAnInt".toInt).
<-: { _.getMessage } <-: = Map left value
Failure(For input string: "notAnInt")
101. Mapping via Bifunctor
import scalaz.syntax.bifunctor._
Bifunctor = functor of 2 arguments
fromTryCatch("notAnInt".toInt).
<-: { _.getMessage } <-: = Map left value
Failure(For input string: "notAnInt")
fromTryCatch("notAnInt".toInt).
bimap(_.getMessage, identity)
102. Mapping via Bifunctor
import scalaz.syntax.bifunctor._
Bifunctor = functor of 2 arguments
fromTryCatch("notAnInt".toInt).
<-: { _.getMessage } <-: = Map left value
Failure(For input string: "notAnInt")
fromTryCatch("notAnInt".toInt).
bimap(_.getMessage, identity)
Failure(For input string: "notAnInt")
103. Validation is Monad
def justMessage[S](
v: Validation[Throwable, S]): Validation[String, S] =
v.<-: { _.getMessage }
def extractId(
metadata: Map[String, String]): Validation[String, UUID] =
for {
str <- metadata.get("id").toSuccess("No id property")
id <- justMessage(fromTryCatch(UUID.fromString(str)))
} yield id
extractId(Map.empty)
extractId(Map("id" -> "notUuid"))
extractId(Map("id" -> UUID.randomUUID.toString))
104. Validation is Monad
def justMessage[S](
v: Validation[Throwable, S]): Validation[String, S] =
v.<-: { _.getMessage }
def extractId(
metadata: Map[String, String]): Validation[String, UUID] =
for {
str <- metadata.get("id").toSuccess("No id property")
id <- justMessage(fromTryCatch(UUID.fromString(str)))
} yield id
extractId(Map.empty)
extractId(Map("id" -> "notUuid"))
extractId(Map("id" -> UUID.randomUUID.toString))
Failure(No id property)
Failure(Invalid UUID string: notUuid)
Success(f6af15db-feeb-4895-8c67-a70a6f947db9)
105. Aside: Monadic DSL
def justMessage[S](
v: Validation[Throwable, S]): Validation[String, S] =
v.<-: { _.getMessage }
def extractId(
metadata: Map[String, String]): Validation[String, UUID] =
for {
str <- metadata.get("id").toSuccess("No id property")
id <- justMessage(fromTryCatch(UUID.fromString(str)))
} yield id
extractId(Map.empty)
extractId(Map("id" -> "notUuid"))
extractId(Map("id" -> UUID.randomUUID.toString))
This reads pretty naturally!
106. Aside: Monadic DSL
def justMessage[S](
v: Validation[Throwable, S]): Validation[String, S] =
v.<-: { _.getMessage }
def extractId(
metadata: Map[String, String]): Validation[String, UUID] =
for {
str <- metadata.get("id").toSuccess("No id property")
id <- justMessage(fromTryCatch(UUID.fromString(str)))
} yield id
extractId(Map.empty)
extractId(Map("id" -> "notUuid"))
extractId(Map("id" -> UUID.randomUUID.toString))
This doesn’t! Notation is inside-out!
107. Aside: Monadic DSL
import scalaz.syntax.id._
def justMessage[S](
v: Validation[Throwable, S]): Validation[String, S] =
v.<-: { _.getMessage }
def parseUUID(s: String): Validation[Throwable, UUID] =
fromTryCatch(UUID.fromString(s))
def extractId(
metadata: Map[String, String]): Validation[String, UUID] =
for {
str <- metadata.get("id").toSuccess("No id property")
id <- str |> parseUUID |> justMessage
} yield id
Pipe-forward operator reverses order of function application (from F#)
For more info on pipe-forward, see: http://stackoverflow.com/questions/1457140/haskell-composition-vs-fs-pipe-forward-operator
108. Validation
• Monadic usage of Validation is incredibly
useful
• As useful as monadic option but provides
why failures have occurred
• Can it get better?
110. Validation is Applicative...
... if the error type is Semigroup
Which of these are applicative?
Validation[Int, Any]
Validation[Any, Int]
Validation[List[String], String]
Validation[String, Int]
111. Validation is Applicative...
... if the error type is Semigroup
Which of these are applicative?
✔ Validation[Int, Any]
Validation[Any, Int]
Validation[List[String], String]
Validation[String, Int]
112. Validation is Applicative...
... if the error type is Semigroup
Which of these are applicative?
✔ Validation[Int, Any]
✘ Validation[Any, Int]
Validation[List[String], String]
Validation[String, Int]
113. Validation is Applicative...
... if the error type is Semigroup
Which of these are applicative?
✔ Validation[Int, Any]
✘ Validation[Any, Int]
✔ Validation[List[String], String]
Validation[String, Int]
114. Validation is Applicative...
... if the error type is Semigroup
Which of these are applicative?
✔ Validation[Int, Any]
✘ Validation[Any, Int]
✔ Validation[List[String], String]
✔ Validation[String, Int]
122. ValidationNEL
Validation[NonEmptyList[String], Int]
Success(42)
Failure(NonEmptyList(
“Tigers”, “Lions”, “Bears”))
This is so common, there’s an alias for it:
ValidationNEL[String, Int]
And any Validation[E, S] can be converted to
ValidationNEL[E, S]:
v.toValidationNEL
123. Putting together the pieces
• Given a map of string to string containing
keys name, level, manager, representing the
name of an employee, their numeric level,
and true if they are an manager and false
otherwise, create an Employee containing
those values if:
• Name is non-empty
• Level is 1 to 15
• Otherwise, report all errors in the map
124. Putting together the pieces
case class Employee(
name: String,
level: Int,
manager: Boolean)
type Metadata = Map[String, String]
126. Putting together the pieces
def extractName(
metadata: Metadata): Validation[String, String] =
extractString(metadata, "name") flatMap { name =>
if (name.isEmpty) "Must have a non-empty name!".fail
else name.success
}
127. Putting together the pieces
def extractLevel(
metadata: Metadata): Validation[String, Int] =
extractString(metadata, "level").
flatMap { _.parseInt |> justMessage }.
flatMap { level =>
if (level < 1) "Level must be at least 1".fail
else if (level > 15) "Really?".fail
else level.success
}
128. Putting together the pieces
def extractManager(
metadata: Metadata): Validation[String, Boolean] =
extractString(metadata, "manager").
flatMap { _.parseBoolean |> justMessage }
136. Putting together the pieces
extractEmployee(Map( Failure(NonEmptyList(
"name" -> "Turing")) Missing required property level,
Missing required property manager))
extractEmployee(Map( Failure(NonEmptyList(
"name" -> "", Must have a non-empty name!,
"level" -> "17", Really?,
"manager" -> "notBool")) For input string: "notBool"))
137. Putting together the pieces
• Building upon previous example, given a list
of metadata, produce a list of employees or a
list of errors
138. Putting together the pieces
def extractEmployees(
metadata: List[Metadata]
): ValidationNEL[String, List[Employee]] = ???
139. Putting together the pieces
def extractEmployees(
metadata: List[Metadata]
): ValidationNEL[String, List[Employee]] = {
val vEmps: List[ValidationNEL[String, Employee]] =
metadata map extractEmployee
???
}
140. Putting together the pieces
def extractEmployees(
metadata: List[Metadata]
): ValidationNEL[String, List[Employee]] = {
How can we swap order of
ValidationNEL and List?
val vEmps: List[ValidationNEL[String, Employee]] =
metadata map extractEmployee
???
}
141. Putting together the pieces
def extractEmployees(
metadata: List[Metadata]
): ValidationNEL[String, List[Employee]] = {
val vEmps: List[ValidationNEL[String, Employee]] =
metadata map extractEmployee
vEmps.sequence[
({type λ[a] = ValidationNEL[String, a]})#λ, Employee]
}
Type annotation necessary due to limitations in Scala type inferencing
148. Lens: Problem Statement
case class Contact(
name: Name,
phone: Phone)
case class Name(
salutation: String,
first: String,
last: String)
case class Phone(
digits: String)
val seth = Contact(
Name("Mr.", "Seth", "Avett"), Phone("555-5555"))
149. Lens: Problem Statement
case class Contact(
name: Name,
phone: Phone)
We need a copy of seth
case class Name(
salutation: String, with first name set to
first: String, “Scott”
last: String)
case class Phone(
digits: String)
val seth = Contact(
Name("Mr.", "Seth", "Avett"), Phone("555-5555"))
150. Lens: Problem Statement
val seth = Contact(
Name("Mr.", "Seth", "Avett"),
Phone("555-5555"))
val scott = seth.copy(
name = seth.name.copy(first = "Scott"))
151. Lens: Problem Statement
val seth = Contact(
Name("Mr.", "Seth", "Avett"),
Phone("555-5555"))
val scott = seth.copy(
name = seth.name.copy(first = "Scott"))
Doesn’t scale - each layer in record structure results
in another layer of copies and duplication
152. Lens
• Given a record type and a field, a lens provides the
ability to focus on the specified field, which allows
accessing the field value and setting the field value
(immutably)
153. Lens
• Given a record type and a field, a lens provides the
ability to focus on the specified field, which allows
accessing the field value and setting the field value
(immutably)
• Translation: Lens = immutable getter/setter
154. Lens
case class Contact(
Record Type Field Type
name: Name,
phone: Phone)
val contactNameLens = Lens.lensu[Contact, Name](
(c, n) => c.copy(name = n), _.name)
Setter Getter
val contactPhoneLens = Lens.lensu[Contact, Phone](
(c, p) => c.copy(phone = p), _.phone)
Setter Getter
155. Lens
•Case class lenses usually use copy in
setter
case class Contact(
name: Name,
phone: Phone)
val contactNameLens = Lens.lensu[Contact, Name](
(c, n) => c.copy(name = n), _.name)
Setter Getter
val contactPhoneLens = Lens.lensu[Contact, Phone](
(c, p) => c.copy(phone = p), _.phone)
Setter Getter
156. Lens
•Case class lenses usually use copy in
setter
case class Contact( •Case class lenses are purely mechanical to
name: Name, author (there’s even a compiler plugin that
phone: Phone) does it!)
val contactNameLens = Lens.lensu[Contact, Name](
(c, n) => c.copy(name = n), _.name)
Setter Getter
val contactPhoneLens = Lens.lensu[Contact, Phone](
(c, p) => c.copy(phone = p), _.phone)
Setter Getter
157. Lens
case class Name(
salutation: String,
first: String,
last: String)
val nameSalutationLens = Lens.lensu[Name, String](
(n, s) => n.copy(salutation = s), _.salutation)
val nameFirstLens = Lens.lensu[Name, String](
(n, f) => n.copy(first = f), _.first)
val nameLastLens = Lens.lensu[Name, String](
(n, l) => n.copy(last = l), _.last)
158. Lens
case class Phone(
digits: String)
val phoneDigitsLens = Lens.lensu[Phone, String](
(p, d) => p.copy(digits = d), _.digits)
159. Lens
Lenses compose!!
val contactFirstNameLens =
contactNameLens >=> nameFirstLens
Composes 2 lenses in to a Contact to First Name lens via andThen
160. Lens
Lenses compose!!
val contactFirstNameLens =
contactNameLens >=> nameFirstLens
Composes 2 lenses in to a Contact to First Name lens via andThen
val seth = Contact(
Name("Mr.", "Seth", "Avett"), Phone("555-5555"))
161. Lens
Lenses compose!!
val contactFirstNameLens =
contactNameLens >=> nameFirstLens
Composes 2 lenses in to a Contact to First Name lens via andThen
val seth = Contact(
Name("Mr.", "Seth", "Avett"), Phone("555-5555"))
contactFirstNameLens.get(seth)
“Seth”
162. Lens
Lenses compose!!
val contactFirstNameLens =
contactNameLens >=> nameFirstLens
Composes 2 lenses in to a Contact to First Name lens via andThen
val seth = Contact(
Name("Mr.", "Seth", "Avett"), Phone("555-5555"))
contactFirstNameLens.get(seth)
“Seth”
contactFirstNameLens.set(seth, "Scott")
Contact(Name(Mr.,Scott,Avett),Phone(555-5555))