So, let's go. So, hi everyone, my name is Eric. I'm going to talk to you today about the EF monad. So, if you want to talk about the EF monad, you will learn about how this is a monad based on the version of a free monad with an open stack of effects and how it's implemented using continuations and all sorts of things. And that would be great and very enlightening. Like, oh, that thing is really cool. It's like the monad to rule all of our monads. That's nice. But then you come back to work and, okay, but how do I use this thing? Where do I use this thing in micro and project? Like, I want to build a microservice. Where does that thing, what does that fit? What kind of effects should I use and so on? So, today I want to give you an example of microservice that we built using the EF monad and how we create our software, how we design it and where the EF monad fits into all of this. So, I work for Zalando. That's a web store where we sell clothes online and it's actually a big store. We sell lots and lots and lots of items and also we have lots of engineering behind all of this because we don't do only the website but also all the logistics that goes behind. We have huge warehouses in Europe and we produce all the software for that as well. So, there's lots of smart algorithms for the logistics and all that we do as well. And in my department called Merchant Operations, what we do is that we onboard merchants and we let them sell their own articles on the Zalando platform. So, if you are like Zara, you can say, okay, I have some stuff to sell too and I can use Zalando as a platform to sell my own stuff. And in the context of this department, we had a small microservice to produce called the article service and the article service is a very simple microservice.  A pair of Adidas, I have a for a given price and I have that many items in my stock. You can use this service to register yourself and say, okay, I can now sell those shoes. And the article service does, it goes through other services. First of all, to check if you're a registered partner, if everything is correct in your contract then talks to the catalog to know if the shoes, they already exist or not, check the stocks and so on. So we started building this and right in the middle we learned that the new service for products that we were using which was brand new, we actually could not use it anymore for some reasons related to the legacy system and to some identifiers. And we had to get back to the old system which was, she's called ZEOS. It's the old legacy Java system which is a big monolith and so on. Right in the middle of the project. So what did we do? Well, we panicked, what do we do? I mean, we have to break everything that we did. It's horrible, right? You take some assumptions on how you build your software and then someone breaks everything. Well, actually we did not re-panic because we relied on a very well proven technology, something that's really nice. It's just called components. It's actually not so new. It has been described a long time ago. So if you read this paper on how to divide the system into components, the point that this paper tries to make is that it's not so much about dividing your system into different functionalities. It's also dividing your system into what changes and what doesn't. And the purpose is to isolate the rest of the system from what's going to change. Try to hide the implementation so that you can be isolated from change. That's probably the most important criterion to use, how you divide your system. So now you hear we are building microservice, we're using components, and you might think, okay, how do you wire them up? What kind of software do you use to do this? So what do you use for dependency injection? So maybe we're using something called the cake pattern. So I don't know how many Scala developers are in the room. Can you please raise your hand? Okay, a bunch of them. So maybe you've heard of the infamous cake pattern. So it was a trial in Scala to do dependency injection using some of the Scala type system features, like traits, mixings of traits, self-types, and so on. Unfortunately, it turned out to be not such a good idea for dependency injection. So maybe we turned out to a Java library, like juice. Juice is doing dependency injection. So maybe we could have used that or say, oh, let's forget about Scala and all this complexity. Let's go back to Spring, and because Spring is the thing, it's Spring Book got everything. So no, actually we didn't do any of this. And we tried to have one more radical approach, like let's try to go back to what it means to do constructor injection. And let's start to build something from this, because constructor injection is actually quite nice. You need something, you just inject it in your component using the constructor, and that's it. And what's missing? If you just use constructor injection, what could be missing from it? Let's take an example. So this is a piece of configuration where you can describe how many threads you need in your thread pool. And this is the configuration that's going to hold this piece of information, and maybe a lot more, like some URLs for your external services and so on. And you can have one version of this application configuration for production, one for staging, one for development. You can describe all of this in your code. And if a component needs that piece of configuration, you can just create a function. Say from config, that's going to take the full application config, it's going to carefully extract just the parts that this component needs for its own association, and that's going to create the component this. It's a simple function. Now I'm just going to slightly modify this function to do almost the same thing, but I'm going to use a reader. So the reader data type is also a function. It's just giving it a different name, it's going from A to B as well. So we can define in Scala an implicit reader that's going to create a reader object, taking a configuration, and returning an HTTP client. And now we have two components, one needing another. The reader definition becomes, I can create a reader for HTTP server provided that I already have a reader for my HTTP client. And then I know how to create an HTTP client, and then I know how to create my HTTP server. So I know how to create both components together and wire them together.  But there is still a bit of ball of play in the code that I showed you, because it's quite mechanical to write all this code. So we automated this to make it simpler using a library called Backdoor. And now you just have to put annotations on top of your classes. And you say, I want a reader for this. And it's going to create the same code. That's very easy. And once you have all those reader in place, it can be at the top level of applications. And now give me an HTTP server. You pass it to your configuration, and then you have one. So in a way that really solves the problem of the instantiation. It's a very simple and well-known functional pattern using a reader that we can really apply in the situation to instantiate the whole application. That's nice. So this is more or less what our application looks like. You have an HTTP server at the top. And there are different routes for the different services, like get a price, set a new price, get the stock, set a new stock. Those rights are HTTP routes. So they need to extract some parameters. They pass all of this to some business services, if you want. There's a bit of business logic in there. And then we talk to external services. They are all clients. So it's like a layered architecture like this. And this is one of the routes. So I won't spend too much time explaining because we're using a DSL for this. This is a nice, actually, in Scala, it's a nice DSL called row, which is a type DSL, where you can describe the routes. And everything is fully typed. And when you extract parameters, you know exactly the type of what you've extracted. So if you're familiar with Haskell, there is something equivalent called servant, where you can do the same kind of thing. So the job of this component is just to extract information from the route, from the incoming HTTP request, that's all it does. And then it sends the extracted parameters to a service, which is the price service. But that component doesn't want to know at all how the price service is working. That's not its matter, it doesn't care about that. So what we want for the price service is just an interface. We don't want to know about the implementation because then when we test the routes, we can be fully isolated from all the rest of the system. So we want to have something like this. We want to have a price service and then an implementation for that price service. But introducing an interface here allows us to really separate components. But how does that work with the reader? Because if you define a reader on an interface, I mean when you create a reader, you need to create a concrete instance. So in that case, you cannot use the reader annotation that I showed before. Because you need to specify, for a given interface, you need to specify what will be the at least one concrete implementation. So in that case, you can use this default reader annotation where you specify that by default, when you try to create a price service from the configuration, you will use this concrete implementation. And then at the bottom of the screen, you can see the concrete implementation, which is using other services. So this works quite well, but as you can see, this is already like a significant difference from other libraries doing benefits injection because there's always one default being specified. Yes. Why didn't we use AKHTP? Because we're using HTTP for rest as a web server for once. And also because the wrap in row, which is the layer on top of HTTP for rest, are fully typed. So internally it's using like HList, extracting all the parameters with their concrete type and gives you the types that you want. And it's even smarter than this because also the return type is fully specified. And then we can produce the entire swagger file describing our web service completely from the code, which is something that we have to internally, we have to produce swagger files describing our APIs. And instead of having going from swagger to code, we can directly go from code to swagger. And we never have to maintain this relationship, which is quite cool. That's the main reason. Okay, so now you understand that we're using readers, so that's cool. But you might wonder, hey, there's a big flaw in your system because it's always a reader from config, which is my application config, to a component. What happens if I want to put that component in the library? That component knows about a given context, that's my application config, but what if you want to reuse it in another context with another application? That's a problem. It's not modular. So actually it is because the reader annotation is slightly smarter than this. And what it does, it says, it creates a reader that says, I can build an HTTP client, provided that you know how to extract a thread pool from an A. And I don't really care what the A is. So in our context, it's the application config. In another context, it could be something else. So this implicit here is just a requirement that says provided that you know how to extract it from A, I know that then I can build from that A and it should be client. So this is a solved problem. This is not a problem. And that's cool because we also extracted some of the components in two libraries and now we're able to reuse them. And the last piece is now that we want to be able to extract a thread pool from an A, that means that we need also to provide implicit going from our concrete configuration to a thread pool. And there's another annotation for this. So basically there's a set of like four annotations that generate all the boilerplate you need to instantiate all your components. It also, so mostly what we've seen is a very system for describing components because the only thing we require is case classes, which is in Scala, like simple data structures and interfaces. It's not really fancy. It's not, there are no type parameters and so on. But you can actually also use a type parameter as a return type for your methods and the reader annotation will also generate the correct reader code in that case. So it's this style of writing components where they are parameterized by a type constructor is also possible. So it's really readers all the way down. Instantiation equals readers. That's nice. So what kind of problems, what have we solved so far? How is your life easier? So unit testing is definitely easy, right? There's the easiest Rubik's Cube in the world. This one is easy because just take your components in like whatever you want using the constructor and there you go. You can test your components in isolation. So that's one is easy. You might think another thing might be actually a bit harder and this is usually the thing that gets really hard when people just want to do constructor injection is how do you do integration testing? Integration testing where you build your whole application and you just want to mock some of the lower level components to make them return pre-canned responses, for example. How do you do this? And this is annoying with just constructor injection because you need to manually rebuild the full tree. So the answer we have for this because this is a tree is, well, there's a theory of tree called tree rewriting and there is even in Scala a nice library doing this called Kiyama. So Kiyama takes on the experience of tree rewriting which is as a concept started many years ago and especially another project called Stratigo. So Stratigo has explored what it means to rewrite trees and Kiyama has imported those concepts into the Scala world. So in Stratigo and Kiyama you can define strategies that are going to be applied in your tree and transform the tree. So we can have a strategy for replacing nodes, for example. So what does this strategy, what does it say? It says, okay, I'm traversing the tree and if I find a node that has the type I want to replace I just switch it with another value and that's it. Otherwise I don't do anything. And then you have combinators which can use strategies like this one everywhere top down which is going to use the strategy and try to apply it everywhere top down until it reaches the bottom of the tree. And with this and a bit of syntax it's actually very, very easy to write tests because you can say build my HTTP server from any kind of configuration and we've seen that it's possible with reader and now replace, any time replace just this component at the bottom of the tree with the mock one and it's just one line of code. And for us it was very important that writing tests should be as easy as possible because you want people to write tests. You want people to think about tests about, I have to wire up all of this manually and this is going to be very tedious because then people don't write tests and that's not what you want. There are still some problems to solve though because actually what we are building when we are instantiating the application is a tree. It's really a tree and sometimes you don't want a tree. You want a graph because some of the components you don't want them to be duplicated. Some of them are doing database access. Some of them are holding connection pools. So in that case what you want is transform this tree into that graph where some nodes are being shared by others and the reader pattern cannot give you this. It cannot give you this. So what you need to do again when we're a tree writing helps is that you can define another strategy for doing this. And this time you're going to work down the tree. The first time you find a node that has the type that you want, you put it on the side and every time you find a similar node of the similar type, you replace it by the instance you first met and this way you're going to rebuild all the connections just to one node and you're going to make your singletons like this. So this is why in the first slide I showed about the main application. We were first creating the HTTP server using the reader for the configuration and then making singletons because most of the time you want your components to be singletons. Actually in reality it's slightly more complex than this and in our case it was slightly more complex because some components have the same type but they need slightly different configuration. So we have two operations, one called modify with which is going to practically modify the tree and put some configuration in some places and the other one is called singletons by that's going to make singletons based on the fact that two components have the same configuration or not. Let's make it more visual. So this is our tree that we got from the reader and as you can see master data is duplicated you know in two of the branches, okay, it's fine. So the first thing to do is we modify the tree and we put a different client configuration for master data and the catalog because they are both using an HTTP client but you want their HTTP client to be configured differently because there are different services. So this is what modify with is going to do. The next step is going to make singletons but this time based on the fact that two things should be made a singleton only if they have the same configuration. So the second call is going to make the singletons but this time not unifying everything all at once based on the type but it's going to unify based on the type and all the value that is in a current node. So eventually we get exactly a tree with the shape that we want with all the parameters that we want. And we can go further so we can also visualize that tree. So this is one of our applications because we have a tree, we can output a dot graph and we can verify that this is exactly what we want. But this is actually quite nice because you also have some kind of architecture diagram produced for you automatically. One very important point though is that because we are doing tree rewriting every time you instantiate a component it's usually not the first time you will do it because every time we rewrite the tree you re-instantiates a new component. So all those components in their constructor need to do absolutely nothing. Do not start any service, don't do anything. So if you need something like an execution context you need to wrap it into an eval monad or make it lazy in some way because you don't want this thing to start every time you create a component otherwise you will be starting it many times. If you want to start stuff you can implement the start interface and implement the start method. And once you build all your application once you've made your singletons you've configured everything you can start your application. And starting the application is again using tree rewriting. Just going down the tree if a node has the start interface we call the start method we collect the results because maybe it can fail. And eventually we grab all the results and we display it to the user saying okay it went okay or it didn't go okay. And what we are doing here also for traversing the tree is slightly different than what we did before is we do an everywhere bottom up because generally you want to start the services bottom up from your dependencies first and then from your higher level services next. This is a reasonable default. If you have a more elaborate starting strategy you can implement your own combinator to do a different traversal of your tree. Okay, so this is how we do dependency injection. We use the reader pattern that any functional programmer should know about. We use tree rewriting to put the exact configuration we want where we want it. Stay lazy, that's very important and then we can start the application. That's quite cool. But wasn't it to talk about F in the first place? No one is shouting, I want to see F. It's coming because now we have nice components. We have things that can be developed independently put in libraries and so on but those components have interfaces. An interface is generally a bunch of methods where you have the name and some input parameters and a return type. And what we want to do here is to be very precise on what the component does and we do this using the F monad. So you can think about the F monad as being a monad. With this additional type parameter here R which is going to track the kind of effects that you're doing. Maybe it's doing some IO, maybe it's doing some concurrency, maybe it's doing some logging, maybe it's doing some state keeping, all sorts of stuff. So unfortunately I don't have the time to go deeper into the subject. I will ask you to have a look at this presentation. I did a flat map of flow. If you want to have more details about the free monad and the F monad in particular I just want to give you some kind of flavor of how you think about the effects. So this is a computation using the either monad. So the either monad is for when you have the possibility of having errors. And in this case an error is just a string. So you do two computations that can both fail and then you can print the results if everything is okay. It's a right value. If it failed you get a left value and then you can say oh there was a problem. Now if you think about the same thing as an effect you will consider that the left case is a request that you make to someone else which is going to be an interpreter and you say oh I got a problem. I don't know what to do with it. And you decide. And if you have a right value you say oh I was able to get value. That's a right value. That's an A inside my right value that you can use. And generally the interpreter is going to say oh you gave me a left request. I don't know what to do either because there's no value that I can continue with. But if you give me a right I know I can extract what's inside the right and then apply continuation to it. Because there might be other computations like for example in the for comprehension. There were other things to do. So this is what the interpreter is doing. And if you can rewrite the same codes that we've seen before with an either effect and it will be almost the same with a bit more type annotations. And the run either here is going to be the interpreter that's going to interpret those effects that you put in your for comprehension. So if you look at the F library in Scala you will see lots of effects out of the box. From reader, writer, state, I mean the usual suspects in functional programming. But you can implement your role. So typically our interfaces they look like this because we generally use concurrency. So we have task effect. We do some logging. So we have a log effect. And we do some flow ID which I'm going to talk about. And then what we return is an F value with this R type parameter which is describing the stack of effects that we're using. And of course. And more precisely this whole definition says I got a R which is my stack of effects. Actually I don't know exactly what R is. I just know that at least it must contain a task effect, a log effect, and a 5D effect. So it's still open about what R should be. And eventually you say oh now I want to really invoke that function and I want to invoke it and get a real result out of this. So then you say this is my stack. So my stack is precisely those three effects. Please invoke the method with that precise stack and then call all the interpreters. And because you've given a special stack and because everything is nicely tracked in the type system, you can only call those interpreters and no other interpreters and you will not get the value out of the F monad unless you've called all the interpreters one after the other. So let's go back to the article service and talk about this flow ID thing. So what is this flow ID that we implemented? So a flow ID is something that a user of the service is giving us to track a given request. That's a very important thing to do in macro services where you send a request but generally this triggers other requests to other services and when you read the logs, it's nice to have one identifier able to tell you exactly what's happening on the different services. So this flow ID has to be transmitted to every method in the call chain, right? It's kind of annoying to have to do this manually, name a parameter, pass it everywhere. So typically this is a good case for a reader. So because there is a reader effect, we implemented a reader for flow ID and a bunch of type aliases in Scala and this is what we do. We can ask for when we are at the bottom of the application, when we really need a flow ID to be materialized to pass to the downstream systems, we just ask for one and it has been implicitly passed across all the method invocations and now we can send it to an external system and if we want to run this method, we need to run the reader, we need to interpret it with the run reader interpreter and pass it the flow ID coming from our client. Yes, yes, yes, yeah, it needs to be passed, yeah.  So let's see another example, logging. So how do we do logging? So we have like an entity for logging. With all the different cases that we want, like info, word, debug, error, and so on. And we can make this an effect and maybe I won't spend too much time on this but the send method is a method provided by the F library, taking any kind of ADT, like a T of V and provided that T is part of your stack of effects, it returns you an F value containing that thing. This is how we send an effect of a given type into our large stack of effects. And then we need to write an interpreter for this. And in that case what we do is that what we really have to interpret those effects is like a concrete logger, so like a type save logger from the type save libraries and which is going to do a real call. In that case, because we are doing functional programming, we really want to evaluate things, especially IO things at the latest moment. So what this code is doing is doing a translation from an effect that's pretty abstract because just a bunch of requests, hey, I have an info logging, that's what I want to do. Hey, I have a debug logging message, that's what I want to do. And it translate this to a more concrete action which is now use a given logger and write to the file system with this. So we do translation from one effect to another in the stack. But there's more importance and a nice thing that we can do now is that not only we can write one interpreter that's going to take our abstract effect and do something concrete, but we can also write other interpreter and some very useful ones. So we can say for example, hey, discard the logs. I don't really want to write any logs. So that's cool thing when you do some testing because sometimes you see people writing tests and then when they run the test, there's logs all over the place and they cannot see anything anymore. But with discard logs, you can say, I don't want to see the logs. I'm not interested in that, just run my test, please. And at other times, we are really interested in the logs because you want to test them. You want to test that you put the right information in your logs. So in that case, what you just want to do is collect them and this collect log interpreter is going to just return you your log messages and you don't care about the value. So you can see what the power of having effects and different interpretation is. It's very flexible. The next great thing about the F-monad, especially if you read the original paper written about the F-monad, is that the F-monad originally is just a monad. So it's very sequential. So you do A, then do B, then do C and track all the effects between all those actions. Here it is. It's a free-air monad. Yeah, so if you read the papers, yeah, Google for free-air monad, absolutely. But in the F library, we implemented also an applicative case where we can have different effects being really executed concurrently. And this is particularly important for us as we are talking to other services. We want things to be concurrent because we don't want to waste time waiting for too many services in a row. So if you want to get the price and the brand of something, we can just do an applicative union of those two calls and then map the results together. We can also traverse a list of articles and make sure all those calls happen concurrently. That's quite useful. So we implemented all these applicative concurrency. It's actually backed up by lots of concrete data types. So there's an effect for Scala Future. There's an effect for Twitter Future. There's one for Scala Zed Task, one for Monix, one for FS2 in Scala. So if you know Scala, there are lots and lots of options for doing concurrency and futures and tasks. And there's a new one now, Scala Zed IO is coming. So all of this is currently supported by the library, except no, not Scala Zed IO, it's just too recent. So you can eventually end up, I mean, you can use the concurrency library of your choice and it's integrated with F. So we've seen like different effects that we are concretely using in our services. One of them is floaty, it's like a reader effect. Logged is more like a writer effect. We have eval, which is for delayed actions and tasks for concurrency. But there's no reader for config. And maybe you've seen some other talks about how you can do dependency injection using the reader monad and at the level of functions, not at the level of components. And this is not what we do. We do dependency injection at the level of components, never at the level of individual functions on all components. And in my experience, that's also a great separation of terms that really makes instantiating the application really separate from using it. Okay, we had some learnings while we try to use the F monad on the real project. So maybe you can learn about that. The first thing is that in some places we started using describing calls like that. We're saying, okay, if you want to get a price, I will return you an F value with this exact stack containing tantas, logged and reader for flow ID. And this makes your life really difficult if you do this because if you have another call with a different concrete stack, you will have to reconcile the two stacks together. And that's, it's not impossible to do, but it's actually quite hard. So what you want to do inside is to leave, to use different style of declaration and to leave the things a lot more open. So this declaration just says, I'm using a stack of effects R and I just know that this stack contains at least task, logged and flow ID. But I don't know exactly what it is now, that I don't care. And then it will be a lot easier to integrate with other calls having other effects. So that's one interesting thing. There's the same thing in Haskell. If you do Haskell, you will have all sorts of monad transformers and they are quite rigid in that sense because if you have different stacks of monad transformers, they might not play well together. If you use the MTL library on the other end, you just have type classes constraints. So that's the exact same idea. Error management can become also quite a challenge if you have different layers because now you have three different possibilities for handling and describing modeling errors. So you can say, either return an easier value, that's one way of doing it, or you could return a data type that's also encapsulating the possibility of an error. That's something that we did. Or you can use an effect and just return an A, but in your stack you have the possibility of declaring errors. That's the third way. So which one should you use? Well, actually we used all of them. And this was a bit messy at first. So after a while, we decided to have some kind of conventions. Like the lower level was always returning explicit error types like either and so on. In the middle, we had more usually using either effect or sometimes more complex error types. You really have to decide how you want to model errors because now you have a lot more possibilities. One thing that we found really cool though that you might not understand right away by reading the slide is that locally, you can add effects just to your stack just for a short while. So you can say, I'm going to do a bunch of calls and I'm going to pretend that just for those calls for a moment, I have this new effect in my stack. I have variable either. And that's quite cool because this allows you to just call the happy pass and forget about errors for a while. And then only at the end, you reinterpret either to get back at either value. So this is quite nice that we can do this kind of stack manipulation by just enriching the stack for a while and then decreasing the stack when you're done. That's really helpful. Another mistake that we made is that if you read tutorials on the free monad, most of the time free monads are modeling like command to another system like as a free DSL for everything. And that didn't work too well. For example, we decided to, let's try to see if get price could be modeled as a free monad. Like it's an action, it's a command after all, get price. So where do we go with this? So if you want to have a component where get price is described as an effect, well, you need a bunch of baller plates to describe your NADT for getting some price. And then you need to describe the method to get price that's going to return the price request effect. And then you need the components which is holding your interpreter to then interpret that program containing price effects. And eventually what you end up doing is, okay, use the components to build a program. The components gives you back a program containing this price request effect. And generally what you want is then, well, interpret that thing into async, for example, and maybe some other effects and get back a result into async. So this kind of dense is always the same and it's not very useful. And it also makes the interface of our components pretty complex in terms of types. And not only that, but all those effects, there's DSL effects like get price, get stock, and so on. They tend to bubble up to the highest level of our application. And then we have a huge stack of effects because it's containing like low level things like concurrency, logging, and so on, but also DSL stuff. So this is what we decided not to do this and have our components return really low level effects like things that are like technical concerns, async, log, and so on. Yes, no, this is still on one. Anyways, yeah. Actually the implementation is more complex because it's not a list. The stack of effects is encoded as a tree for performance reasons. So this is the kind of interface we end up with just using low level type of effects like technical ones in our interface and not DSL ones. And maybe to finish up with, we can discuss about another component that we use which is about time. So if you want to, it's very useful to model time as a component, especially if you're doing functional programming. Because if you want to know what time is now, this is a side effect, right? This is an action, if you do it twice, we'll get two different results. So this is important that this thing is well encapsulated. So should it be an effect or should it be a component? So let's try to see what would be the difference between the two. So for example, we use this time effect or this time to implement a right clicking. So if you want to implement right clicking, you need to know what time it is. So you have a component for right limiting and if you implement a component for time, it will ask that component, hey, what time is it now? And that component will reply with the time it is now. And if you want to test, you can use Grafter to just switch that component for something that will always give you the same time, always. Or which is just going to give you a list of times and which will cycle through this every time you make a new call, for example. So you can really control the passing of time. So this is definitely a possibility. Another possibility would be to use the time effect. So this time when you get the status, you get results inside the time effect and your interpreter for the time effect could either do the real thing, push the real time, or do some for some testing. You could have an interpreter that just returns always the same time. And the major difference here that we see is that most components generally are really black bits. So when you do something with a component, you don't want to know about the implementation. Once you add effects to the interface of that component, like time in that case, you open to the client of the component the possibility to do things slightly differently. So for example, the client can completely ignore that effect, like the logging. We can discard all the logs. Or it can just use a different notion of time. Or it can take asynchronous calls and make them completely synchronous. That's another possibility. So I think in terms of design, this opens like a new possibility when you do component-based design. So your components become not completely black box, but they kind of open up to the client a bit of control about the effects that they are generating. And this is quite cool as a design possibility. So in a nutshell, what did we do today? I want to re-enphasize, and I think that components are really important. Because we need separation of concerns, it's nice to have interfaces. It's how when we have systems, especially business systems that are evolving pretty fast, that's how we can make sure we can isolate part of the systems and make sure we don't infect. If there's a change, the rest of the system will not have to change too much. I think the constructor injection is quite good. If you add a bit of syntactic sugar on top of it, and that's what we've tried to do with Rafter and through the writing, and we get something where we can be really efficient. So if I have a component and I need to add a new dependency, I generally just have to add a new dependency. I don't have anything else to do. I don't have any reader to modify anything else. I just need to add my dependency. So it's really nice because we can evolve the application. We feel very productive with this. And eventually what we need to do on our services is to make sure we have a precise definition of what they are doing. And the F-Monad is a great way to do this because we can be pretty specific about what they are doing. And we also, we can give a bit of control on the clients about all the low-level technical effects that we're using if they want to do something different. So please use the libraries. Give me some feedback. Come and work with me at Xanando in Berlin. If you're interested, we have lots of things to do. And that's it for today. So in a way what I was saying about Monad Transformers is that they are very fixed. So if you have a reader T of writer T of option T of something of IO, it's a data structure that you, it's hard to make it interact with let's say an option T of reader T of IO. Which would be like in a different position for example. Or with another stack that has either T in the mix. The F-Monad uses what's called an open union of effects. So just says that you have at least those effects but you can have more. And it makes integration between two different calls having different effects a lot easier. So the order does not matter in the definition of what you're doing. It matters a lot in the interpretation.  So the classical example, if you run either and then state, you will get a different result as if you run state and then either. But this is also tracking the types because the type that you get back is different. The first one will be a pair of the states and then either value. Second one would be a left value containing an error or a right value of the state. So in the constraint, it's just a set. No, if your interpreter's commute, you can switch them. If they don't, you can't. No, it's also, the implicit are smart enough to be more or less resilient to changes in order. I cannot completely guarantee that because it's quite complex, but yes. So I think you need to put a bit less. Most of the time because it's just using implicit. So the notation we saw with the type parameter and a bunch of column underscore or something is just some syntactic sugar for using implicit. And implicit, they tend to flow pretty well. You couldn't have some problems sometimes when you call the interpreters themselves, but otherwise it's okay. Yeah, so it's not so good, but that's, I mean. So one thing that the freer monad does over a classical freer monad is that it solves the issue of quadratic bands, right? If you associate to the left different flat map, flat map, flat map in a normal freer monad, you rebuild the structure every time you do it. That's not very efficient. The F data structure solves this and that's fine. But that being said, you are still in your program building a data structure and then interpreting it. And that has some cost in terms of allocation. No, because what we're doing is really calling services and IO is like dominating everything. So this is not a problem. That being said, there's a very interesting project in Scala called Effects with a K, which is using the limited continuations to pass interpreters or handlers directly to where they should be used. And this is a lot more performance, but it cannot do things that the F monad can do at the moment, which is handling resources and properly closing resources and doing applicative, which is quite important for us as well. Yes? Yeah, one question I had is, have you found debugging to be a challenge? Because I've started using the FS2 library recently and when you do something like run log there, so all the effects get run, but when something fails, it's very difficult to sort of track where exactly, which effect exactly failed, or which line in your code cost that failure. So that is something I've found a bit of a challenge. With FS2? With FS2. Is that a challenge or, so you run all these effects at the end, right? There's a failure or something, a stat base gets printed out and from that, it's very difficult to sort of figure out where that effect is. I think the main issue is due to concurrency. It's the fact that computations are being sent to the threat pool and then you don't have the full context of what created that computation. So yes, this is definitely a problem. But I don't think it's a problem that's really related to F. If you don't use concurrency, it's quite okay. The only issue in a way when you read the stack traces is that you have lots of garbage because you have all the F machinery that you have to read and then all the, I don't know, the cat's machinery for functional programming and then you get to your line of code. So that's maybe the only issue. Yes. Be able to run through all. Sorry. I was here, but someone else? Oh yeah, yeah, yeah, yeah, yeah. Okay, please, please. But once I realize that it's exactly what I did. I run through all the indices. Where's the message? I ought to go there. Okay, start again. Question please. Try success failure. So, oh, no, so there's an either effects in F and there's also like a more elaborate error effect where you can track failures, errors, or values. So that's also, so that's also what we get with the different error effects that we have in here as well. But we also have there's a safe effect which is quite interesting because it allows you to use a bracket operator. So a bracket operator is when you want to like use a resource and if anything goes wrong, you want to make sure that it will be cleaned up afterwards. And this is actually quite hard to implement properly. It's exactly like resiliency. Yeah, very similar. All right, so we'll have to set up the next week. Thank you.


Good evening guys, I'm Hemant Sharma, I'm working as a senior UX designer at CK12 Foundation and I've really not presented such a small talk before, but I'll try my best to do it in five minutes. So can I get a quick hands up on how many of you are designers here, okay. So this is originally a 3R presentation, but I'll try to be done in five minutes because I've really scrapped a lot of slides and I've just made it a small glimpse of the whole presentation. If you miss anything catch me offline and if you're interested in discussing more let's do it. So what is design, right. By the way, can you guys quickly tell me the difference between or the similarities between doctors, priests and designers, okay, well taken. Any other similarity, quickly. I believe based on my experience no two of the same kind agree with each other easily, right. So I've had a lot of arguments with fellow designers. I have seen the same thing happen with doctors and even the priests. Yeah, you have a lot of other kind of people to add, but yeah, thanks for adding it. So this talk is going to quickly give a brief of why is design necessary and why is it important. So design has no single definition. It does not follow rules. It only follows guidelines and philosophy. It is functional. It has a selling point and design is subjective. It is design. Design is done for a purpose and design. If you look at it from an advertisement perspective, it's a concept. If you look at it from a UX perspective, it can be a solution. If you look at it from a visual design perspective, partially it can be color. And there are a lot of other areas of design that are extremely important to survive, right. Throughout this three or four minutes that I have left, I'll try and touch upon two major topics in that previous list that you saw. This is an example of an art. Can people quickly point me to what this is? What do you think this is? Sorry? Lord Ganesh. Okay. Anything else? Tree. Tree. Fish. Okay. The painter calls this an apple tree, right. The reason I'm showing this is because art can be interpreted in different ways because it is majorly relying on emotion and expression of mind, right. It doesn't have to serve a purpose. It doesn't have to solve a problem. Design needs to solve a problem. So I don't think this can be interpreted in many different ways, right. So that's the importance of design and that's the difference between design and art. So practice safe design, use a concept. I really love this. If you've heard the other quote, you can easily relate it to that and it's extremely important. So conceptually, it's better to have a simple and smart concept and one idea is always best because you kind of help your audience also interpret your idea in the same way and you don't open up many options for guesses. This is one good example. I wanted to show I have a lot of other examples but because the time is short, I just stuck to this. Here the thing I want to stress upon is that it's not only limited to Photoshop or Illustrator or any design tool you use but the concept is all the way taken till the execution phase, right. The lights are really switched off where it is unnecessary color. So there are three models I want to talk about. One being additive, that is what you generally see on your screens. That's the hex values for colors that you use in CSS and stuff. That's called RGB. They are basically light emitted sources and then you have the subtractive model that are generally paints, inks, dyes and all that. That's why for printers you see cartridges that have C, M and Y and then you have the RYB model which is the red, yellow and blue model which predates the modern color theory. I'll talk a little bit about the RYB model. So here you have the red, yellow and blue. These are generally called primary colors. How many of you knew this? Okay. For those who don't know it's extremely important to understand this, I'll tell you why. That's the whole point of my slide, right. So these are called primary colors. When you mix yellow and red, you get orange. When you mix red and blue, you get purple. When you mix blue and yellow, you get green. So orange, purple and green are called secondary colors. When you mix each primary color with its adjacent secondary color, you get a tertiary color. So to summarize, color wheel is not something a designer who was on a hangover, got up and thought about using Vibhgyar and who did circular color gradient. It's well thought out. When you add blacks and whites, you see different tones of the colors. Without any tones, all the primary, secondary and tertiary colors are called the pure colors. We have different color schemes, monochromatic, pick one color in the color wheel and design the whole thing with that tonality, right. Analogous, pick one color, pick two adjacent colors and design the whole thing with that, right. Then complementary, pick the opposite color in the color wheel and design your stuff. There are other color schemes that I cannot talk about because I'm running short of time. Then we also choose colors based on emotions. These are called hot colors. These are called, sorry, cold colors. The image is not loading. You can look up the slide. Oh yeah, this is called cold colors. There are other different colors based on emotions as well. Similarly, there are a lot of other concepts of design which are very important, well thought out and which are extremely essential when you think about design. When you think about any of the design concepts that I mentioned in some of the beginning slides, right. So why design? The whole motive of why I want to present this deck today is to just request the developers to understand the design from in-depth and from more of a philosophical and theoretical perspective, just to appreciate design, right. And I have worked a long way in my career and I've seen a lot of gap between designers and developers. I think if each other understands the subject of the other community, you can have a healthy relationship, right. That's all. Thank you.


अप अप पकष्टान्डों पब बच्टान्डः लिए में देपिनेडले गास्टान्डांडान्डी चितायम पैक्स्टान्डः पीषटान्ची भीट्चे आप तोगे लिए मैतेर्द बहुतान्धी कुईया, आब पाक्स्टान्ची पिटान्जी आप रहा Pioneer में को को अई � अगान के प्लिटिकल सिस्त्रम की बात होगी तो जाहर है बरे सगीर के अंदर रहने लोगो को जब मुश्यरती हवाले से बहुत से मसाल का सामना करना पडा तो मुसल्मान लीडर्षिप ने यह फैसला किया के एक कते एक मुश्रे के अंदर रहते हुए तोगों के मसाल का हल मुमकिन नहीं तो उसके लिए ज़ोरी है के एक और नहीं रयासद का वजुध जो है उसके लिए पूशिष की जाहें और बिलाकर जो है पाकिस्तान का वजुध इसी मसले के हल्के तोर पर दूनियां के सामने नाजर आया लिए यही ताल्ळोग है पाकिस्तान के वजुध और प्लिटेकल सआश्वौलोगी सात उसके रिलेशनषिप को जिसकी भजा से हम पलिटेकल सआश्वौलोगी के अंडर ईछुश्ँन जाएव पाकिस्तान सास्वालोगी के सबच्च्च्चिश सिस्त्रम के सबज्यक्को परनाय की कोशिष कर रहे हैं because before partition, muslim leaders under the umbrella of all indians, muslim league struggled for the establishment of a separate state for the muslim nation because muslims had their own identity, muslims had their own identity it was necessary for that identity to be served that the society where they were not allowed to have their own identity for them a separate state should be established in the post independence era, pakistan faced many issues and due to those issues, pakistan was not able to establish a proper democratic system in the country why this system could not be established because of which Pakistan was asked for a democratic system these issues and hurdles were mainly defined by many political scientists and mainly farmers as the identity crisis in pakistan, the geographical part of pakistan, the area of pakistan, there were many identities those identities had their own identity it was necessary that when a state was established then all these identities could be associated with a state in a larger interest where it is possible to work for a state but in the case of pakistan, there were many facts where these identities could not be established with a political system because of which the political system could not be established in the working condition along with that, there were many other issues where there was a legitimate crisis the legitimate crisis was a political science debate in the historical context and due to this, a proper legal representative government could not be established but today, in the 21st century, the legitimate system has entered a new dimension where the government has determined the legitimacy of the system so here, it is necessary to see that in pakistan, there was a participation crisis there were issues related to the distribution of the resources and due to meeting all these issues, the government was asked to work then the political system of pakistan has evolved with the passage of time experience different modes of authorities like governor rule, bureaucratic rule, military dictatorship democratic governments under military shadows and then now presently the free election based governments in pakistan, the various models are operative sometimes parliamentary form of government sometimes presidential form of government sometimes due to the various issues in those systems some forces were dominating sometimes the government had to put a rule sometimes the bureaucracies were dominating sometimes the military dictatorship was also experienced but sometimes the proper democratic governments also came who established the government of election jeet but with all these things we have to understand is that the sociological perspective about the evolution of pakistan's political system that shows that ethnic, religious and other minor identities remained main hurdle in the development of pure democratic political system i.e. what i said earlier is that in sub-continent because a lot of external forces came from outside who introduced their cultural characteristics here because of that the cultural system which came in existence the caste system which came in existence was very strong the caste system which came in existence in Punjab in Sindh another system was established the tribal culture which developed in blochistan all of those are their own characteristics if those characteristics were to be part of the system then they needed to have an element of modernization and development and how they could come that the social context in pakistan was changed it was necessary to change that social context that education was promoted in pakistan socialization was focused and communication was focused when the social context modernized on these elements when it was not focused on that on the education of people on the communication skills of people it was not focused on the role of leadership political participation was not brought to the table and especially people were not encouraged that how they could give their rights to the city how important their character is for the country so obviously the proper political system of pakistan also had a lot of problems with the social context and the political system itself did not properly perform its functions that it modernized the society it developed the society so the two sides of the problem that pakistan was facing that is why today also in the political system of pakistan there are a lot of challenges, a lot of problems and the scope of political sociology provides a very interesting debate to both the students and the political philosophers


The Kraft Foods Company presents the Great Gildersleeve. He brought to you by the Kraft Foods Company makers of Parquet, Margarine and a complete line of famous quality food products. Summerfield. In Gildersleeve's experience there are two kinds of evenings. Those on which a man has either got to get out of the house or go crazy and those on which wild horses couldn't drag him out. This is one of the latter. Having stuffed himself comfortably at dinner He settles into his easy chair, pats his tummy, and beams upon his niece and nephew. Leroy, where are you going? Upstairs. I gotta do my homework. Couldn't you do it down here? Oh, sure, I guess so, only I thought you said... Well, ordinarily, I think it's better if you do your homework in your room by yourself. That's true, my boy. But just this once, if we're all very quiet. Eh, Marjorie, what do you think? Think you could concentrate down here? I guess so. Why? Leroy? I can concentrate anywhere. Good. I just thought it'd be nice if we spent an evening together for a change. After all, I've hardly seen you children lately, except at mealtime. Man likes to feel his family around him sometimes. I thought we could have a fire, maybe? Oh, I think that'd be nice. We'll just spend the whole evening quietly together. Concentrating. Leroy, you do what you're doing. Marjorie, do what she's doing. I'll do what I'm doing. What say? Make no difference to me, long as I get this done, that's all. Ah, you'll get it done. After all, if we're all concentrating, we won't interfere with each other, will we? Besides, it'll be good practice concentrating. That's one of the most important things you can learn in school, my boy. Concentration. Learn to concentrate. Okay. Well, stop talking now, Leroy, and do our work, shall we? Who's talking? Well, don't. You can't talk and concentrate too, you know. By the way, what are you working on there? Arithmetic. Arithmetic. Marjorie, what are you working on? Social. Oh, social? Well, yes, I'll read my book. Anybody seen my book? What book? The book I was reading. Well, I didn't know you were reading a book. What book? The book. The book. The book I started. What's the name of it? How do I know? I was reading it, and I had it right here. Somebody's moved it. Birdie! Uncle Mort, nobody's touched your book. If you can't remember the title, what was it about? Maybe I could... I can't remember that either, but I was reading it, and I know that. Mr. Gelsie, did you... If Birdie, did you move my book? No, sir, not me. I don't touch a thing. If I find a thing laying around anywhere, I dust around it. I know, because that's the way I was brought up, and that's the way I am. I don't touch a thing. Not me, no, sir. Did I do what? My book. Have you seen it? Book, book. What kind of book, Mr. Gelsie? What did it look like? Well, it had a cover. It was blue or red, maybe. Anyway, it was some color. That is a scrap of paper stuck in it where I stopped reading.  Fat book with a scrap of paper. It ain't this one. Let's see. Birdie, you're wonderful. I don't know what I'd do without you. I knew it had a title. Anthony Adverse. Anthony Adverse. What's the matter with Anthony Adverse? Well, you don't want to read that. It's 10 years old. My dear, some of the greatest books in the world are 10 years old, and more. But Anthony Adverse. Oh, let him read it, and let me do my homework. I will simply remind you, my dear, that this book was chosen by a book club. It wasn't just written by some Tom Dicker Harry, you know. Let's see, who did write it? Never heard of him. Mr. Gelsie, pardon me, but... Yes, Birdie? I got all them grocery bills any time you want to check them over. You asked for them, remember? Oh, well, thanks, Birdie. That's fine. Any time? Not tonight, Birdie. I'm pretty tired tonight. Some other time. Yes, any time. Just never know they're piling up out there. Yeah, pretty tired tonight. Our day. Long day, too. I'm driving myself too hard, I'm afraid. Mistake. You know, well, who's stopping you? Well, how can I figure with you talking all the time? I'll leave it to anybody here if I've been... Marjorie, have I been talking all the time? Uncle Mort, read your book. All right, Leroy. Sorry, I won't say another word. Chapter 2. Is that as far as I got? This is an awful complicated book. Off a lot of people in it. A lot of plot, too. Can't even remember the part I read. Maybe I'll just wait till the movie comes out. It's come out. It has? Common gone. What am I reading this for, then? Guess I'll read a magazine instead. After all, I worked pretty hard today. Now, there's my idea of nothing at all. I asked you my dear, take a look at... Oh, the constant... What's the matter with him? Read your magazine and let me read my book. Yes, yes. There's a life for me. Yes, sir, that's for me. That's the way I like to end my days. How? There's an ad here. Picture me following his wife, I guess. Anyway, they're holding hands. Oh, what of it? They're on a ship going someplace, leading on the rail, looking out to sea at the sunset. She's wearing a cap and smoking a pipe. Looks like he's taking it easy. What's the point? Well, the ad says that... Just think, darling, in only 15 years you'll be able to retire on $160 a month. Say, look into this. Read it. Yes, sir, no more worries, no more cares. Since Mary and I decided to take care of our future with Indestructible's New Easy Way Plan. Just 15 years and I can retire. Travel, play golf, take life easy. Do all the things we wanted to. Oh, I'd love to travel. I'd rather travel than anything. 160 a month at age 60 guaranteed income as long as you live. Oh, I've always wanted to go somewhere in a boat. Says here, don't delay. Mail in the coupon today. Even it was only a little boat. Even if it didn't go anywhere much. Uncle, what else does it say? Well, I've got this coupon you fill out and then beside it here there's a... Guess it's a Balinese dancing girl. I don't know where she comes in, but anyway... Oh, Uncle, let's do it. Do what? Let's go somewhere in a boat. Well, it wouldn't be bad. See the world, visit points of interest. Oh, let's... Of course, you don't get this money for 15 years. I'll wait, I'll do anything, but let's go somewhere. Well, it would be something to look forward to. Lee Roy, how would you like to go on a trip? Trip where? Everywhere, all over the world. No, no, my dear, let's not get too excited. Uncle, Mark's going to retire. No, Ken. Well, not right now, but I'm considering it. Boy, I'd sure like to retire. You retire from what? You haven't even started. No, my boy, you have a long full life ahead of you. A life of useful endeavor, I trust. Who wants that?  I'm going to retire when I'm 21. Better start saving your pennies then. By the way, I wonder what this easy way plan costs. Doesn't seem to say here anywhere. Sand in the coupon, Uncle. It says sand in the coupon. I suppose it's an annuity of some kind. Sand in the coupon, and they'll explain. Yeah, sand in the coupon, Uncle. Now don't rush me. There are a lot of angles to this. A lot of financial considerations. Uncle, it says just sand in the coupon. Well, what can I lose? Come roistering around, wanting sodas at all hours the night, huh? I was just talking up. Yeah, lad, I caught you. Pee-vee, could you let me have a stamp? We never seem to have any at home. Yes, I guess you could. I'm going to get this thing off tonight, if possible. It's important. Now, did you want the three-cent stamp or the one-cent? We have both. Well, this'll take a three. And a three seems to be more popular. That'll be three cents. I have an air mail if you'd care to go that high. Well, what the heck? I'll blow eight cents. This is important. Air mail's only five now. Five? Pee-vee, don't tell me you're selling cut-rate stamps. No, the government has just produced a fare. There you are. Thank you. And you have three cents coming. And... What do they put on these? I imagine that's harmless. Pee-vee, you know what's in that envelope? No, Mr. Geltis, leave behind. No. Pee-vee, let me ask you a question. This may be a little personal. Most questions turn out that way. You don't mind? I don't have to answer it. No, I guess you don't.  Pee-vee, fuel for thought. Pee-vee, have you ever stopped to think what you'll be doing at the age of 60? I'm doing it. I'm 60 now and then some. Oh, yeah, well, that's so. Well, I guess this wouldn't help you much then. Too bad you didn't get started younger. Get started? Well, if you'd played your cards right, Pee-vee, if you'd shown a little more foresight, you wouldn't be down here working every evening. You'd be home enjoying life with Mrs. Pee-vee. I don't know. I wouldn't say that. All right, you'd be off someplace. Yellowstone Park, the Grand Canyon. Well, what's your matter with Summerfield? There's nothing to matter with Summerfield. You're not more comfortable than the Grand Canyon. Don't you ever want to go anywhere? Don't you ever want to retire? What for? Why does anybody want to retire? So you can take life easy. So you can spend more time with your wife. I'll tell you, I consider I've been pretty lucky. Mrs. Pee-vee and I have remained on good terms all these years, and I wouldn't want to risk changing it. And I don't know if she could stand to see any more of me than she does. All right, Pee-vee, have it your own way. But if you ask me, it's a lot of sour grapes. The idea. A man your age having to work here till 10 and 11 o'clock at night. Mr. Gillifield, do you know what keeps me here till 10 and 11 o'clock at night? No, what? People coming in here after I've closed wanting to buy stamps. Well, I guess I can take a hint. I'm extremely sorry to have troubled you, Mr. Pee-vee. Oh, please don't misunderstand. I'm all right. I was merely trying to make a suggestion for your own welfare, but I see it's too late. Mr. Gillifield. In the future, I'll buy my stamps from Beckham. Mr. Gillifield, don't go away angry. Please, I wouldn't want that to happen. Well, all right. I was just carrying my little Joe. You know, I'm afraid my sense of humor runs away with me at times. Oh. Well, maybe I was a little touchy, too. By the way, there's the mailbox. Don't forget to mail your letter. Oh, thanks for reminding me. I bet you'd like to know what's in that letter, wouldn't you? Well, never mind. Just remember this. As long as you're a friend of mine, Pee-vee-old boy, you never have to worry. The Great Gilded Sleeve will be busy planning his retirement again in just a minute. Well, Mr. Lang, what do you have to say about Parquet Margarine tonight that's new and different? The story is really about the same. In fact, I was just going to mention that Parquet Margarine has been of the same fine quality all through this period when spreads for bread have been scarce. Craft is using the same top quality ingredients as always to produce delicious, nourishing Parquet. Oh, and that's something we really appreciate, Mr. Lang. Whenever I can get it, I like to serve Parquet Margarine with hot toast for breakfast or with bread and rolls for lunch and dinner, because it always tastes just right. That's what millions of families have discovered. Parquet's fresh, country sweet flavor has made it one of America's best-liked spreads for bread. Today, of course, all spreads for bread continue to be scarce, and you may not find Parquet Margarine every time you shop. But when you do, you'll find it the same high quality it's always been. And you may be sure craft is producing to the limit of available supplies. So look first for delicious flavor fresh Parquet. P-A-R-K-A-Y, Parquet Margarine. Now let's get back to the great Gilder Sleeve. Since mailing the coupon, that is to take care of his future, a new sense of security and well-being has come over him. It has been noticeable in little ways. You know, Marjorie, I was passing the Army and Navy store today. They got a yachting cap in the window down there. I've always wondered how I'd look in a yachting cap. Why, George, I'm tired of shaving myself every morning. Why should I? Maybe a shoe shine, boy. Give the place a little class. My place too classy for most of my customers right now. Just name one of the regulars that had laid down a buck for a manicure.  Throckmorton P. Gilder Sleeve. Yeah. Boy, certainly. If you had a winsome little blonde holding my hand, I'd buy a manicure every week. So would plenty of your customers. I don't know. I got to feel that most of the regulars are just buy a haircut and look at her for free. When you talk about a shoe shine, boy, I tried that. When? Four or five years ago, a colored fellow named Willie gave you Don Good Shine for 10 cents. Oh, yes, I remember Willie. Well, he would have stopped to death here if he hadn't went in the Army. Hey, how's that? Nice and smooth, ain't it? Oh, that's fine, Floyd. Fine. The trouble with this barbershop is you can't make any money this way. You ought to expand. I do all right. What'll you do when you're too old to work? Just keep on working, I guess. That's no way to talk, Floyd. You ought to arrange to retire in a few years. Take life easy. It's tough to pile up a retirement fund with a class of trade I got. Well, you do have some cheapskates, of course. You said it. Well, Judge Hooker, good morning, Judge. Come in, Judge. We were just talking about you. Will you be along, Floyd? I'm just the one so politely from Mr. Gilda's leave here. Sit down. I'll be right with you. Talking about me, you say, Gilda? I was just giving Floyd a little advice. I'll pass it along to you, too, Judge. You fellows ought to start thinking about your old age. Indeed. Certainly. If you had any sense, you could both retire in a few years and spend the rest of your life just lolling around. I can't say that's a prospect that appeals to me, particularly. Sounds good to me, Commissioner. I'd be willing to start tomorrow. How do you work it? I'll tell you, Floyd. Personally, I've made arrangements so I can retire when I'm 60. Nice, fat little check coming in every month. Well, insurance? Well, it's a form of insurance. Annuity. That's the place to put your money. You got any annuities, Floyd? No. Got a thousand dollar policy on my wife that's about my only investment. What about you, Horace? You got any annuities? No. Since when have you had one? I happen to have a little foresight.  How about the judge's fix, so he don't have to worry? Yes, sir. I bet he's got a bundle laid away someplace. Maybe I have, maybe I haven't. Well, if you buy an annuity, you can't miss, judge. You put this money in every month, and then when you're 60... I'm familiar with the principle of annuities. For a fellow like you incapable of planning your own investments, I suppose it's an excellent arrangement. Who's in...  Well, we could snap it. Finish him up, Floyd. I've got to be in court by 10. Take your time, Floyd. I want the full treatment. All right. You're all done now. Just slap on a little lotion, and there you are. All right, you old goat, get in the chair. Thank you. See if I got some money here. George, I'm afraid I'll have to give you some pennies, Floyd. I ain't got nothing against pennies. Wish I had a billion of them. I have to go to the bank and get some cash. I can just make it, Floyd. 48, 49, 50. Right? Well, it's the price of a shave. I'll owe you the tip, Floyd. I'll be in later in the week. Goodbye, Judge. So long, Floyd. Gotta go to the bank. Him and his manicures. Super banking, isn't it? Yes, it is. I suppose you're here on official business? Oh, no. Purely personal. Just want to deposit a couple of lamb chops. Date of the order of, uh, myself. Well, ten dollars is enough. No hundreds. Brock Morton, be Gildersley. Good morning, Mr. Gildersley. Making a deposit, I presume. No. Just one little folding money. A five and five ones, please. Yes, sir. Brock Morton, be Gildersley. What are you doing? Looking me up? You ought to know my signature by now. Just a formality, Mr. Gildersley. Banks, rigmarole, and red tape. Come on, I'm in a hurry. Oh, Mr. Gildersley, if I'm afraid... No, what? Well, I'm sure you saw this. What did you say? I said you saw this. Speak up, confounder. I can't hear you. I said your account is overdrawn. And three dollars and twenty-six. What? I'm sorry. But under the circumstances, I'm afraid we can't honor your change. I've got a balance of over a hundred dollars. Oh, now, Mr. Gildersley, these things happen. Not in a well-run bank, they don't. I've got half a mind to do my banking somewhere else. In fact, I would if there was another bank. Oh, my dear sir. You better check your accounts, Mr.... Well, maybe you'd better check yours. Six and eight is fourteen and nine is twenty-three. What does it mean when you're overdrawn? Four, seven, eight, twelve. One to carry. Is it like being broke? Leroy, for heaven's sake, he's trying to add. And it's worse than being broke. If you're overdrawn, you owe the bank money. And if you don't pay them, well, something happens, I'm sure. Once and for all, get this through your heads. I'm not overdrawn. The bank has made a mistake and I've got to find it. That's all. That's what you always say, Anki. Have they ever been wrong? Why don't you check these figures, my dear? Here. Here's the balance, September 1st. The bank and I saw eye to eye, September 1st. Well, what's this, your deposits? Yep. Well, there's a mistake of a hundred dollars, right here. Where? Here, adding the deposits to the old balance. You gave yourself a hundred dollars too much. But, George, that must be it. But that still doesn't explain where the devil's all the money gone. I'm going to get to the bottom of this. Birdie! What's she got to do with it? We're spending too much money, that's what. Birdie, you're supposed to keep track. Did you call me, Miss Gilsley? Yes, Birdie. Now, I've asked you to keep track of our expenses, haven't I? Yes, sir. Well? I've been keeping track, they're getting awful high. This is a fine time to tell me. I've been trying to tell you before, Mr. Gilsley. I tried to tell you a day before yesterday. That's right, Uncle. She did. I can't tell you if you won't listen. Well, let's look into this right now. Have you got the bills, Birdie? I got the slips, yes, sir. I'll bring in the slips and you'll see. I knew this was going to pop, Birdie. Leroy, sometimes I wonder if you're possessed of ordinary normal judgment. Do you think this is an opportune time to ask for money? I only asked for a quarter. Gee, if I'd asked for a buck, but a lousy quarter. There's no such thing as a lousy quarter. I haven't got a quarter. From now on, every penny counts.  Yeah, I guess so. Mr. Gilsley, here's the slips. Uh-huh. Sit down, Birdie. Now, the total grocery bill was $78 last month. Why is it so high? Stuff is going up, that's all. Ridiculous. Prices haven't moved that far. Let's see, for instance. Well, there's two pounds of peas we had for dinner last night. $0.60. Used to be $0.30. We'll eat no more peas. Make a note of that, Birdie. Yes, sir. Beans gone up, too. $0.50 worth of beans there. See that? String beans? I don't like them anyway. Cut out the beans from now on. What about the meat? There ain't any. Found it. We've got to eat something, Birdie. Chicken? $0.80 a pound, Mr. Gilsley. Forget the chicken. Potatoes gone up? Yes, sir. Bread? Yes, sir. See, the whole grocery bill here is $0.78. Last September, our bill was under $0.50. We're eating too much. We're eating less than we used to. Yeah? I can't understand it. Let me see some of these slips. Darn things. You never can read them. What's this here? Looks like blood. That? That's bluing. That's gone up, too. What's this? Ammonia. We've got to cut out these frills, Birdie. From now on, nothing but necessities. Yes, sir. That'll save us about $0.15 a month. We've got to save substantially somewhere, Birdie. What's this? Oranges a dollar and a quarter? Yes, sir. That's for the orange juice for breakfast. Leroy's got to have his orange juice if he's going to grow. Leroy's too big already. Look at this bill from Hogan Brothers. Pants for Leroy, $0.365. Shirts for Leroy, $0.2 for $0.80. Jackets, $0.650. And look at him. What do you do with these new clothes, Leroy? Obviously, you don't wear them. These are the pants.  Are they the best pants you have? Yep. I need some new shoes, too. They'll have to wait. This is serious, children. These bills for September, Hogan Brothers, $0.85, $0.60. Oh, I had to have a coat, Anki. I won't need another one for quite a while. Groceries, $0.78. Milk and meat, $0.45. That's over $200 right there. Bernie's salary, Dennis' bill, Peavey's bill, Plummer's bill, Leroy's music lessons, Paris cleaners and dyers. Why, do you realize? What?  There's $375 in bills right there, just for necessities. I'd be willing to give up music lessons. No. I'll give up cigars. Anki, I'll take the coat back to Hogan's. I haven't even worn it yet. No, my dear, we'll find a way. Bye, George. Doorbell, I'll get it. Good afternoon, Mr. Gildersleeve at home? Yes, sir. Who shall I say it is? Mr. Bradley, Clifford Bradley. Yes, sir. Mr. Gildersleeve, Mr. Bradley wants to see... Mr. Bradley? Mr. Gildersleeve, I understand you're interested in our plan to retire and live like a king on $160 a month. Oh, get off my... Get off the property. Get out of here and go... If you're looking for fine quality, delicious flavor, and good nourishment, and you're spread for bread, look first for parquet margarine. Whenever your food dealer can supply you, you'll find that parquet is the same fine quality as always. Country sweet in flavor, rich in food energy, and with 15,000 units of important vitamin A in every pound. The Kraft Foods Company is maintaining the high quality that has made parquet a favorite spread of millions. And we're continuing to produce all the parquet we possibly can. Our only regret is that there's not more available at present to meet every family's complete needs. So please be patient when supplies are temporarily short. And remember to always look first for that good name and quality spreads, P-A-R-K-A-Y, parquet margarine, made by the Kraft Foods Company. We're saying, Mr. Gildersleeve, the beauty of our plan is that you hardly notice the little payments. You get so used to them. But boy, when that old 160 a month starts coming in. Yeah? And another thing that we like to emphasize, our company has been in existence since 1907. Is that a fact? So it's safe. That's why I say you're making no mistake in lining up with our company. Well, why don't you take your foot out of the door and come in? Thank you, Mr. Gildersleeve. I will. Good night, folks. The Great Gildersleeve is played by Harold Perry. It is written by John Gleedon and Sam Moore. The music is by Jack Macon. Included in the cast are Walter Tetley as Lee Roy, Louise Erickson as Marjorie, and Lillian Randolph as Bertie. Judge Hooker is Earl Ross, and Dick Legrand plays Mr. Peavey. This is John Lang saying good night for the Kraft Foods Company and inviting you to listen in again next Wednesday for the further adventures of The Great Gildersleeve. Ladies, when you're hurried and the family's hungry, a quick, sure way to satisfy appetites is to serve delicious Pabstet cheese food. Children love Pabstet's rich cheddar cheese flavor on crackers or toasted sandwiches, and you'll be amazed at how quickly Pabstet melts into a smooth, tempting cheese sauce for macaroni, egg, and hot vegetable dishes. Be sure to have Pabstet cheese food on hand for all occasions. Buy it in both delicious varieties, Pimento Pabstet in the red package and Golden Cheddar Pabstet in the familiar round yellow package. This is NBC, the national broadcasting company.


Live from Stanford University, it's theCUBE covering Global Women in Data Science Conference, brought to you by SiliconANGLE Media. Welcome back to theCUBE's coverage of the fourth annual Women in Data Science Conference. This Global WIDS event is the fourth annual, our fourth year here, covering it for theCUBE. I'm Lisa Martin, joined by Gianluca Icarino, the director of the Stanford Institute for Computational and Mathematical Engineering. Gianluca, it's a pleasure to have you on the program. Thank you. It's a pleasure to be here. So the Institute for Computational and Mathematical Engineering, ICME, tell us a little bit about that and its involvement in WIDS. Yes, so the institute has been, was funded 15 years ago at Stanford as a real hub for computational mathematics at Stanford. The intention was to connect computations and, in general, the disciplines around campus towards using computing for evolution, for starting new ideas, for pursuing new endeavors. And I think it's been extremely successful over the years in creating a number of different opportunities. Now, WIDS started four years ago, as you mentioned, as part of an idea that the prior director of ICME, Margot Gerritsen, had with few others. And I think the position of ICME at the center of campus really helped bring these events sort of across different fields and different disciplines. And I think it has been extremely successful in expanding and creating a new, completely new movement, a completely new way of engaging with a large, very large community. And I think ICME has been very happy to play this role and I'm continuing to be excited about the opportunities. You mentioned expansion and movement. Two things that jump out, expansion. We mentioned fourth annual. Only started, this is three and a half years ago, November 2015. And we had the pleasure of having Margot Gerritsen, one of the co-founders of WIDS on theCUBE last year at WIDS. And I loved how she actually said, very cheeky, WIDS really started sort of as a revenge conference for her and the co-founders, looking at all of the technology events and industry events and seeing a lack of diversity. But in terms of expansion, there are 150 plus regional WIDS events this year. In 50 plus countries, they're expecting over 100,000 people to engage. So this expansion and this movement that you mentioned, it's palpable. Tell us about your, what is the impetus for you to be involved in the WIDS movement? Well, I think my interest in data science and in WIDS in particular is because of the role that ICME has in the education at Stanford. We obviously have a very important opportunity to renew and remodel our curriculum and provide new opportunities for education of the new generations. And clearly starting with the opportunity of having such an audience and reaching so many different disciplines and so many different fields helps us understand exactly how to put that curriculum together. And so my focus and my interest has been mostly on making sure that ICME aligns with these new directions. And when we established the institute, computational mathematics didn't really not have data as a very, very critical component, but we are adjusting to that. Clearly it's becoming more and more important and we want to make sure we are ready for it and we make sure that the students through our curriculum are ready for the world out there. So let's talk about the students and the curriculum. You've been a professor at Stanford for a very long time. Before we get into the specifics of today's curriculum, tell me a little bit about how you have seen that evolve over time as we know that we're sort of, in terms of where the involvement in women and technology and STEM fields was in the 80s and how that's dropped off. Tell me a little bit about the evolution in that curriculum that you've seen and where the ICME is today with that adaptation. Yes, certainly the evolution has been very quick in the last few years. We have seen a number of opportunity emerging because of the technology that is out there. The fact that certainly for data science, both the software and the hardware and the technology, the methodology, the algorithms are all in the open so that there is no real barrier into sort of getting started. And I think that helps everybody sort of getting excited about the idea and the opportunity very, very quickly. So we don't really need to go through an extensive curriculum to be able to already solve problems and have an impact. And I think that perhaps is one other reason why we are sort of in a level playing field, right? Everything is available to everybody with relatively minor investment at the beginning. And so I think that's certainly a difference with respect to other disciplines where instead it was a much more laborious process to go through before you can actually start having an impact, start having a real opportunity to change world and to have sort of your vision, sort of impact in the world. So I think that's definitely something that data science and the recent development in data science have created. And so I think in terms of our role, sort of continuing role in this is to perhaps expand the view of data science as not just the algorithm, the technology, the statistical learning that you need to accomplish as a student, as a newcomer into the field, but also is other elements. And I would say certainly the challenges that we are, that are posed to data science today are challenges that have to do with the ethics, with privacy. And so these are clearly difficult to handle because they require knowledge across disciplines that typically are not related to STEM in a traditional sense. But then on the other end, I think it's the opportunity to be really creative. Data is not analyzing on its own, right? It needs the input, our sort of help in creating a story. And I think that's another element that I think makes data science a little bit different than other STEM disciplines that tend to be much more aesthetic, much more sort of a cold if you like. I think the- That's one of the things too that I find really interesting is if you look at all this statistical and computational skills, as you mentioned that a good data scientist needs to have is we look at some of the challenges with the amount of data being created. So you mentioned privacy, ethics, cyber security issues. The creative element is key for the analysis. Other things too that interest me and I'd love to get your thoughts on how you see this being developed. And the curriculum helping is empathy, collaboration, communication skills. Where is that in the curriculum? Like how important are those other skills to the hard skills? That's a great question. And I think where is in the curriculum, I think we are lagging behind. And this is one of the opportunities that we have to actually connect to other places on campus where instead the education is built much more closely around some of these topics that you mentioned. So I think, again, the real advantage and the real opportunity we have is that the data science in general reaches out to all these different disciplines in a very, very new way, if you like. I think it's probably one of the reason why it's so attractive to younger generation is the fact that it's not just the hard skills. You do need to have a lot of understanding of the technology, the foundational statistics and mathematics and so on. But it's much more than that. The communication is very important. Teamwork is extremely important. Transparency is very important. There are really all these elements that do not really make, they really didn't have a place in some of the more traditional disciplines. And I think that's definitely a great way of sort of refreshing our way of even considering education and curriculum. When you talk to something like the next or the younger generations, is that one of the things that they find or are they pleasantly surprised knowing that I need to actually be pretty well rounded to be a successful data scientist. How I analyze the data, how I tell a story. Is that something that you still find that excites but surprises this younger generation of data scientists? Certainly it's a very important component of the excitement that I see out there. The fact that you can really build a story, tell a story, communicate a story and have an impact immediately, quickly. I think it's something that the newer generation really see as a great opportunity. And rightly so, I mean it has been very difficult for more traditional disciplines to have the same level of impact. Partly because the communities tend to be very close, very limited with a lot of scrutiny. I think what we have in data science is that it's really a lot of, can do attitude, a lot of really creative force that is behind basically this movement, but in general data science. I think that may be helpful. But you're right, the impact is so potent and we've seen it and we're seeing it in every industry across the globe. And it's such an exciting time. Well, John, look, we thank you so much for sharing some of your time on the program this morning and look forward to hearing more great things that the ICME is helping with respect to women in STEM over the next year. Absolutely, thank you very much. My pleasure. We want to thank you. You're watching theCUBE live from the fourth annual Women in Data Science Conference here at Stanford University. I'm Lisa Martin. Stick around. My next guest will join me in just a moment.