Felly ddech chi'n ddweud oherwydd, dwi'n gobeithio gan 10 yrdych, iddyn nhw'n gwneud eich gwahodd yn ddod. I wneud i'r cyfrifiad hynny, dwi'n gweithio, sydd wedi'u gweithio'r gweithio'r gweithio'r gweithio, a'r gweithio'r uniongyrch yn y Gymraegici Rhyf, i Gwyrdd E3G yn Llywodraeth, wedi gweithio'r unrhyw ymddangosill, a'r pryddysgu yw oedd yn y cyfnod, for SIF and for the European Climate Foundation, looking at where the North Sea's grid project is going. And it was actually through that work that I came to a sense that the market systems we have are not working like a lot of other people, and that with this fundamental point, our moment of change. I remember I was asked recently, we've been organised as well as that, we've organised a series of climate gathers. And one of the leading American climate policy people was there in the west of Ireland and said, what's Europe ever done? What do you do after the heat wave in 2003? And I was able to come straight back and say, we put together a radical and the most modern and most effective climate and renewables and third energy market package of measures. And I was very proud in that time to play it, to be one of the people involved of many in terms of the climate and energy package, starting with that ETS being set up in 2005. And then that very clever trick, by my mind, a trick, but political act by Dimas, the Environment Commissioner, and P-Balls, the Energy Commissioner, to get the heads of state committed at an early stage in 2007 to a radical 2020 strategy, this climate and energy package, and putting it at the heart of their whole political agenda. And seeing then their ability to bring those packages, climate package, renewables package, third package of market reforms, through the council, through the parliament and into reality in 2009. And it was, I think, a really good bit of politics at that time. And included within it, as you say, to hide the North Sea's offshore grid, which is just one element in the strategic approach that the European Council, European Commission and Parliament were taking. It's interesting, I listened to Mary Dawn in last week, she was speaking in Donato Your Force meeting, and she said, if you look back in 2009, how much has changed and how much has changed for the better? In that plan at the time, we were expecting, or there was targets being set, that for 2030 we would see photovoltaics coming down to a price of one euro a kilowatt hour. And that's already arrived in 2012, 2013. You know, if you look at how we've actually performed in that sort of time period the last 10 years, particularly in the electricity side, we have more problems in the heat and transport, but that sort of 4% and 5% year on year growth across most of the European states in development of renewable electricity, largely onshore wind as well as PV, we have really achieved a lot of the objectives that we thought we would, or that it has delivered significant investment and significant decarbonisation of the power system through that energy policy package and measures. But also I think if you're honest now, people are looking at it, it's only starting to kind of this realisation, I think it's coming into the political system in the last year, that we're starting to see some real consequences of that success, we're starting to see limits of what's possible under current policy. And the limits, for example, when you see with the scale of German renewable power generation in solar and wind on certain occasions, the spillover effect on that into labour and transmission systems and the knock-on effect in terms of market price being driven right down to zero, which affects not only the investment decisions around backup other fossil fuel power plants or other backup generation, but also investment in renewables itself. Or if you look, for example, at the damage that was done by the Spanish political system withdrawing out in a very inelegant manner from the contractual arrangements they had in support of renewables and the deep damage that was done to investment certainty in renewables through that sort of action. Or if I can maybe take the example of the North Sea's offshore grid, which as I said I've been fortunate in the last year or two to visit many European capitalists talking to people about what's actually happening. To take that as an example of how many things aren't working, how we haven't actually developed a European approach to this critical electricity power market system. And that's not to undermine what has been very good work that we've carried on by the three working groups that were set up within that North Sea offshore grid. But I think they'd all acknowledge that we still have a nationalist and still have a kind of a lack of political leadership in response to the opportunity that exists from power cooperation and developing an integrated market. It was remarkable to hear Mary Donnie speak last week of instances where two European regulators couldn't come down to the basic cooperation to allow the CABRA project to develop, which was a project that was put in the European economic stimulus response to the crisis five years ago just connecting the Danish and Dutch markets, which has now got to be dropped because the regulators couldn't actually come to cooperation in terms of the management of trading regions on it. Or again, my example, I've never listened to what one of the TSO operators in northwest Europe referring to the fact that they couldn't even get another national government, to model what the power effects would be if you allowed trading renewables across two different states. Or again, a recent example, where Tina, the TSO in that north German area, was being driven and asked by the commission to include the capability of the power grid they were building out into the North Seas to have mesh capabilities so that down the line we could add other lines onto it and start trading across Europe. And they point blank refused. And I guess their bankers and the EIB and whoever the finance repeat parties behind that were saying, well I don't want that, that's not a big additional cost, it might only be for 5% of the facility. But I don't want to do that because what certainty do I have then what the trading arrangements are for the renewables and that grid that I'm funding. And therefore I just keep it simple, I keep it radial routing from the offshore North Seas power generation site into the single market because that may be much more expensive, that may be highly inefficient compared to a new European integrated approach but at least I have a little bit of certainty around it. Or again just to cite examples of how we have a problem at this present time, the fact that Marys Mariddon has said that the European Union had also funded a huge investment in offshore wind turbines which are sitting on the dock rustling in Bremenhaven because there wasn't a possibility to get the agreement for the grid connection to actually put them into place. They're built, they're ready, they're paid for by the European citizens and they're sitting on the pier. So we have a real problem to take that one exit maybe kind of market area with that problem in that area and we have a problem in the wider sense of trading renewables based on success in many months because now we didn't expect maybe the multi gigawatt introduction of PV in wind in the system so quickly and that knock-on effect that would have on the energy market. As you're saying having that kind of target market model based on an energy market based on what the fuel price is but which didn't expect you would have such a large chunk of renewables where the fuel prices are relevant or indeed you would have other needs for flexibility where you need to intervene to support that renewable power system and therefore you're led up with a market that's not real and the actual energy, this old traditional market based on oil or gas or coal price no longer applies. So that's the context within I suppose looking back 10 years where we've come to and where we need to go now. I want to just use a couple of slides just to help some of my thinking on it. The first one is just to show I suppose the other factor at the present day which no one expected even five years ago which was the effect of shale gas in the whole political psyche on this issue. Because what clearly came out of my sense of listening to the sidelines of the energy council minister's meeting which occurred in Dublin earlier this summer was that the ministers and the heads of government are fixated on the American shale gas competitive advantage. Remember here in the Institute here in Peter Altamire the German environment minister cited the fact that they're producing the energy or electricity at two cent a kilowatt hour from shale which is just wiping the floor of anything that we can possibly produce. And I suppose that kind of figure either for industry, European average price of 11 cent kilowatt hour or household 18 cent compared to those figures for the US industry 5 cent for industry or 9 cent for domestic users is a fundamental issue with the heart of the debate at this present time. Now whether those figures are accurate or not whether those Chinese electricity prices are based on a real profitable future for Chinese utilities and a deep grid development are not we won't know for 10 or 12 years, we may know very soon if we find out they're developing credit difficulties but whether the American price is fair and accurate or not whether that carbon, whether the full externalities in terms of methane release from the shale production or whether even it's just a balance sheet play for some of those exploration companies that's a tough one to call but we do know that it's an element in the mix in terms of why I think we've lost a certain confidence in our energy policy approach in the European Union and we need to get it back together again in the next year and a half to get ready for 2015 negotiations to set our 2030 strategy in place. You can't ignore that as one of the issues that's in the back of the politicians. It's not even in the back of the politicians mind I think it's in the front of their mind, front and foremost. The North Sea's offshore grid I think is one of the examples of the projects that actually can be our response. My personal and people of different views I'm not so sure we're going to be able to dig up Europe in the same way that they can dig up upstate New York or Pennsylvania and pull the shale gas out. I'm not too sure if the climate can take it. That's my personal view and I think that the alternative in terms of what our natural resources are I think does come from renewables and I think it comes from the set of integration that we were committing to seven years ago but we haven't actually delivered. As I said we're stuck in a nationalistic approach to the whole energy market development. The E3G is doing some work on this project as I said we're just doing some scoping work at the moment we haven't completed it but just there's some scoping work in terms of the various projects that are possible and we have a lot. I mean there's a whole series of NCOE devising kind of offshore grid projects which could be developed to take it very low. I suppose we know we're looking at the possibility of addition these two authentic reactors are in the UK and indeed very attractive prospect are in France because you get that balancing you get north south flows that are possible from such development of such infrastructure. At the UK four gigawatts of connectivity at the moment are remarkable. After coming out last week saying we've got a major problem we've run out of power possibly in two or three years time no recognition within that analysis as far as I can see that actually interconnection could be one of the ways of giving them energy security. Old thinking in my mind in terms of it I can't rely on the French whatever about the Irish or the Norwegians. But I think it's an indication of where we're not thinking in an interconnected way at this present time within Europe. But across this northwest region and in my mind the solution of the approach in Europe we're not going to be able to get all 28 countries together into some new flexible kind of unified market. It is best to do this on a regional basis and then connect at a latter stage in terms of various markets solar connecting up to the northern wind and ocean resources. This project North Sea's Grave was very much also a formation about developing of the North Sea's wind and the Irish seas and Atlantic Ocean energy resources. But even as I said separate to that I think the grid infrastructure itself is critical because the grid infrastructure starts to give you some of that security and balancing capability that is increasingly difficult within the nationalists the national market approach will take the present time. For Germany to be able to manage its target for 2030 I don't think they can do it on an isolated Germany only basis. I think Helen was saying in some of the modeling that was done for the 2050 projects they were looking at least 30% of the power needs for that 2030 target coming from such interconnection from neighboring countries. And the reality is while there was two and a half billion I think approved last week within the connecting Europe facility for some of these projects projects of common interest the reality is that when we build you a fraction of the interconnection points that I believe we need and there's only in these various projects I think there's only about three or four that are in any way in any sort of advanced planning stage the vast majority of that network under current policy and current development went to a certain extent I think our 2030 generation mix will be set. So if you delay this and if you try and come back in retrofitted to the existing generation mix that you would have in this inter-period you're going to get a very strange and inefficient and uneconomic solution. This is Siemens paper and there are various other papers. It was paper I mentioned at the European Climate Foundation they did a very good paper for that 2015 analysis and they saw it by 2030 at 430 billion euro benefit to the European Union by taking this integration approach rather than a national market approach. Siemens have done some similar work and basically set out three different report publishing pages here around you could go this on a national way you could try and get a balanced system or you could go for an optimum location choice. And that optimum choice does have that investment you need an investment in that grid to make it possible 30 billion euro investment but the savings in power generation the optimisation of efficient power generation supply sources be it solar in the south wind, wave or other possible long term power supplies hydro in the north see to getting a net savings of 45 billion and we need I believe these sort of solutions to answer that scare around American share of gas and how we can be competitive. If I can then just a very general sense of where I think the politics may go from here Francois Hollande in his press conference for the second second big press conference of his presidency came out and said Europe needs to lift Europe needs to go on the offensive rather than just constantly on the defensive we set out four various areas where they might do it newton employment and other different areas but one of the four was development of a strong electricity and energy community in North West Europe and in Europe he said I think the lines we said if we don't move now Europe will be erased and I think he's serious about it and I think he's waiting for the end of the friend of the German election for whatever new government German government emerges to actually go back to that traditional driver of European policy French-German agreement around the next advance in the union I think and the institute here has been fortunate in terms of we've been very interested to visit the Potsdam Institute in Berlin we met Professor Schellenhooper and Dr Oeddenhoffer and others who are involved close to German political thinking our sense from that is that the German government will do a deal whoever is in power that there is going to be in the second half this year some sort of major step up in terms of European political engagement for stimulus for integration and for self-sufficiency I mean how do we answer that American shale gas competitive threat or how do we answer the long-term security issue we have in terms of reliance on Russian gas or other energy resources if we are not shown to be capable and serious of actually integrating and driving a policy here and I think I think there is a possibility that the UK government would also buy into such a shift because as I said as their off-gen report showed last week they have a problem and they have no cheap solutions if they go on a purely nationalistic basis and to a certain extent perhaps on a regional approach this North Sea is also really 10 countries in the north west you overcome some of the political difficulties that come by trying to follow a big European initiative this is a regional initiative which is possible and fundamentally I suppose it is a simple diagram that you are working on just in terms of they work a lot on these kind of format of measures that you can range between a centralized market to a decentralized market or from a European solution to a member state solution what we have at the moment is a lot of countries heading towards a centralized and national solution that kind of realisation in the UK government that they have a problem because the power market has changed one which was traditionally based on what the fuel price was, the marginal price of electricity determined policy, been out of date and it is the capital price which is now determined whether it is nuclear or CCS or renewables and so that intervention they are making there in their power market performance to actually very much from the centre from the treasury and then go to that interventionist, centralized and national state approach and you could look at a variety of European countries and apply the same analysis that is where we are going where I think we need to go is towards a European and also a decentralized market approach not to abandon completely the kind of benefits and advantages that you may get from full market competition and from innovation that comes if you set it up correctly so how do we do it? it is not easy stuff if people have the answer to this I was joking with Adam last night we would be selling ourselves in the beach somewhere with a big cigar and a glass of champagne on the other side because this is tough stuff and it is difficult to policy because things keep changing and it is complex market mechanisms, complex technology it seems to me that there are three possible interventions moving to a European and steel market based solution one is around targets, our investment certainty around grid infrastructure interconnection development and I think it does have to be driven by certain strategic we cannot just let the market alone to determine and design a long-term transmission grid which takes 30 or 40 years it is almost to develop it was interesting to meet one of the engineers who designed the Northpool grid he said God it was a fantastic time no one was looking over your shoulder you were just an engineer you were told to go in and design the best grid for this interconnection of the North and Scandinavian countries you were left to other engineers to work out technically how it would work the cost of capital was zero the risk of not being paid was zero the level of political planning difficulties was zero we are not going to be able to do that as easily this time but we do need a strategic intervention from a political level towards higher levels of interconnection which give us some of those balancing capabilities and which reduce the overall cost and reduces the cost of the power generation mix across the North West European region and that needs to be done with urgency that can't be just the two and a half billion connecting your facility that is not at the scale of the transition if we are really serious about decarbonising our power system that we need to do so that ramp up needs to occur very quickly and I suppose recognising always one of the caveats on why this is complex recognising what John O'Sullivan in Aerogridd says right who is doing some work for NSW in this that DC meshed grids will not be the same as the synchronised AC system and it still leaves us, you know, there are still complex engineering issues around how you manage DC which on a for example the Irish grid it's not giving you inertia we've seen already what their own East West interconnector all sorts of complex trading arrangements can arise that you don't predict when you put in such infrastructure but I think we have to if we don't build a fiscal infrastructure I'll build a market arrangement mechanism it's not going to work this key fundamental driver that we need secondly it's clear that we need some sort of new balancing flexibility arrangement to support capital investment in new power generation that is actually centered around this new low carbon future that is and that's not just an awkward or a kind of a simple capacity payment mechanism for some in a fossil fuel plant that might see it as a lovely way of keeping a lifeline to the future it has to be fundamentally designed to create the flexible conditions that makes this variable renewable power system work because it is the only one large scale power system we have available to us to counter those international competitive threats that we have last and not least in fact probably foremost we need to really set up the market mechanisms to allow demand management to take off all the mechanisms are now in place the technology is advanced I was talking to someone last night the wonders of these new Raspberry Pi devices I don't know if you've seen them but this is a new very slim almost credit card sized device that gives you huge capabilities in terms of monitoring, censoring photographing, reporting and it's so cheap 20 euros now you can do something that 5 years go to cost 200 or 2000 and taking the sort of work that Martin Curly and Intel is doing here are showing a risk building Glen Dimplex and really run with it providing them a next day trading mechanism, half hour trading mechanism for the price of electricity which allows people to plan forward allows innovators to come in and say I'll provide you that electricity I'll deliver the service I'll take some of that benefit from that market flexibility that exists, that price flexibility that's going to be key because it's not that key to actually managing the curtailment problem that's starting to develop around wind because you're pumping up demand at a time when you need it and you're cutting it back when you don't and it shouldn't be on the bounds of possibility to set up as I think the commission was looking at you're applied into day trading and flexibility mechanisms and trade on a really clever basis in Europe so that our excess wind that advantage we have in terms of this power here, power in here the time when we want it through that grid, through very sophisticated and simple at the same time yesterday trading demand management mechanisms it was interesting we were talking to Maradona as I said at this at the EUROFORCE meeting you came back with very simple straight questions straight away yes so how does a politician sell this to people how do you explain this as a project that actually wins public support because that is the biggest obstacle the biggest obstacle is politics and I said I don't have a huge sense I haven't had a huge sense in the last two years of any real leadership or confidence within the European political system that we can actually take this step to a completely decarbonised power system and actually beat your American China while we're at it and we can I think it's a safer, better, longer and better for Europe to be the world leader in efficiency and in the use of flexible renewables than digging up the confidence to try and squeeze the last molecule of methane out of the ground and burning it and losing two thirds of the power in the transmission losses that occur from there on and I think it is in some way it's around that message about European security Europe's future and designing the system going back to that last most foremost one around demand management designing this around human needs designing it so that it's easy for someone to do it, designing that energy management system so that it's integrated in such an obvious simple everyday way to people's lives that it's like the next iPhone it's something which is very easy to use which is intrinsic to everyday life which is not a huge moral or difficult dilemma it's actually selling this as the next step in what you want as an individual to be able to do, to have to share its status as well as saving your money and it's not the beyond demands of our possibility in Europe 500 million people well educated with good engineering companies and good utilities to switch the whole utility model to switch the power marked model so that it starts there by people saving power saving money and the whole system balancing itself and much further away I think that's part of where we need to go that sounds very broad and laudable and very easy to say but it is actually thinking if we don't get those messages right everything else is not going to work


Hello and welcome back to the craft box. My name is Brent and today This is the second episode of a brand new series that I started last week I don't many of you probably didn't know it was a series, but it's kind of like a discussion video series Last time I Was talking about my favorite world on screen Hopefully right now some of my favorite comments from that one that of your favorite words, but today I decided that That there was one thing that was like really really annoying about was a 101 that just like really small little Niggly thing that I kind of dislike And that's the potion vendors like there's only two of them Why why is there any two of them? I don't want to go back to Wizard City or go to the Arcana me every single time I want a new potion like what is this? What is this witchcraft? Why can't there be more? Why can't there be one on every world like it's very hard to like have a potion vendor in every single world like Why why not like seriously what why? Like I just don't understand if I was to do one thing with the game. That's just such a small we update But something that I would love so much would be to have a potion vendor in every single world Like in the commons area of every single world like it was really good when the Arcana one came in because everyone's like Oh my gosh another potion vendor fantastic And it's actually easier to get to then the one in Wizard City, which is great because the spiral doors right there And you just like run down this corridor boom and you're there But like why can't there be one in every single commons area of the game like one in Mirage one in Polaris One in Marleybone one in Mooshu one in like whatever world you can think of just have a potion vendor Like is it that hard to do I? Don't appreciate running all the way to Wizard City every single time But yeah, what do you think about that? What do you think about the? Potion vendors like do you think there should be more one in each world or do you like how there's only two one in the Arcana and then one for everyone else who can't get to the Arcana in Wizard City Like what do you think that is a question for today? What do you think about that? Because I'm honestly not not a fan not a fan. I don't like going to was a wizard city every single time So yeah, that's the question for the day. What do you think? Question for the week. What do you think about the potion vendors? So yeah, just a short video These videos are only gonna be short generally If you have any other topics that you want me to talk about or see my opinions on also Leave them in the comments below But um, yeah, thank you for watching or if I can subscribe and if you've already subscribed press the we little bell So you know exactly when I post another video and a member crafts outside the box


Hi, everyone. Thanks for coming to this talk.  Some background about me, I work as a web developer. I build websites for financial products, and we use functional programming for that. So as you can imagine, I have experience building user interfaces with functional programming. So this talk is like a distillation of my broad experiences building those user interfaces. And one of my aims is to show you existing solutions and how they don't quite match up in my experience, and then show you how we can do things better. So this is an overview of what I'm going to do. One of the things that I think a lot about is how to make the task of building user interfaces better. So it's not just purely functional user interfaces. It's about purely functional user interfaces that scale. So let's take a moment to define what scale means here. The easiest thing to do is to make a solution or library simple. When you have a problem, you can come up with a simple solution. That's the easy thing to do. But that doesn't always work, because when the problem statement changes or your requirements change and they will change at some point, then because your solution was so overfitted to the problem, you end up bumping against the edges of that. Or your solution will work only for some specific use cases, or it will not work when you have a more complex problem in the same vertical slice, but more complex. So it doesn't work. So I built a library called Conquer that I hope scales properly. So you can define it for one specific. So you can use it for one specific use case. And I hope to show that it can adapt easily to changing requirements and changing complexities. So that's what the talk is going to be about. Basically two parts to the talk, which is an overview of the existing UI landscape and the Conquer UI library. So this is the guiding principle behind Conquer. How do you make things scale? There are basic tool sets that you need to provide to the users of your library. And it's best if those tool sets are minimal. You don't want to have 10 different tools for 10 different use cases. You want to provide a handful of tools for a lot of different use cases. And they should be orthogonal. So you can combine them, mix and match tools to solve a huge variety of problems. So I've tried to adhere to this principle. I try to remove things from Conquer more than add things to it. So yeah. And just to give you a quick example of scalability. So scalability on one end would be that is it easy to write a Hello World program in Conquer? So this is slightly better than a Hello World program. The Hello World program in Conquer would just be text, hello sailor. So you just display some text on the UI. And this basically wraps it in a button. It's a very simple declarative code. I hope everyone can understand that. And what it does is it shows a button. By the way, this entire presentation is a Conquer application running in my web browser. So I can show you live running widgets. And on the other, not really on the other end, but one of the more complex things that you can do is build a to-do list. That's the benchmark test for any UI library. So this is a running to-do list application where you can add does. And you can edit them by double clicking. And you can mark them as complete. And you can delete them, and so on. And you can obviously filter them. But I don't show the code for that. That's also pretty simple, but it's not here. And the entire code to do that, except for the filtering, is literally this, 18 lines, including spaces and everything. And I want to emphasize here that this is idiomatic code. So this is not some fancy HTML code golf kind of a thing. So this is how you would normally write applications in Conquer. And that's what I mean when I say it scales. To-do list is not a very complex application. If you had to define its functionality, you can define it in a paragraph. So the code for it should not be two pages long. So that's what Conquer tries to do. And obviously, this code will not make a lot of sense to you right now, but hopefully at the end of the talk it will. And please feel free to ask me any questions any time, because just me going through features and syntax is going to get boring. So if you have any questions, especially I'm not an expert in things like React or any other user interface libraries. So if you think that you know of a framework that can do things better, just feel free to stop me and tell me. And I'll be happy to know that. And I'll try to improve Conquer. OK, so yeah. And if you really wanted to play code golf, this is the same code. You can compress it down to a tweet. I tweeted this out sometime back. So you can actually implement to-do MVC in a tweet. And yeah, so let's start with the existing UI landscape. We're going to go slightly back in time. So we're going to think about how UI definition is a difficult problem. So if you think of UI, it's really two things. It's a user interface. So the user provides some input. You allow the user to provide some input, usually through some input hardware. And you use that input to perform some calculation, which is independent of the user interface. And then you provide feedback to the user, generally by drawing lines on some kind of a display device. So it's really simple. And if we wanted to just write an API for exactly this, just have a function called to accept input, have a function called to write something to the display, then what would happen? So this is how things used to work. You had direct access to the rendering surface. So you can draw a square there. You can write some text there. And the rendering surface was persistent. So you can write something. And it will show up on the display device. And then next frame also, unless you change something, the same thing will keep on displaying. So this is a very simple declarative way of handling rendering stuff. What this doesn't take into account is that, so this is an example. So it's easy to draw a circle. But it doesn't take into account how you respond to user input or events from outside the system. So a simple thing would be that you wanted to animate this circle in a particular direction. So you would have to do something like this. And the way generally things happen is that you have some kind of a callback where every second the callback will be fired. And then you have to update the state of the circle on the screen. You have access to the direct rendering interface. So you can just change the position of the ball on the screen. Some complication arises here because you have to erase the previous position. It's all persistent. So you have to erase the previous circle. And then you have to draw it in the new place. And that can get complicated because erasing means replacing it with a background. So you have to keep track of what the background was before you drew a ball on top of the surface. So it gets slightly complicated here. What people came up with is instead of updating just the position of the ball, at every frame, just redraw the entire screen. That's much easier to keep track of. And then you have some kind of a state function which keeps track of the position of the circle. So that's basically immediate mode, where you have a state with the position of the circle. And then every frame you draw the entire background and then the entire whatever objects you have on screen directly there. So this is immediate mode, where you have a rendering function that renders the entire screen in one go, every frame. And you have callbacks that change the state. So this is how it was for quite a long time. And then people had to complicate it. So they came up with this thing called retain mode. Now why do we need retain mode? So when we are thinking about a single circle on the screen, it's very easy. It looks totally uncomplicated. You don't think that something could go wrong with this. But what if you had 10 different circles on the screen, all moving in different directions? And you have callbacks changing the positions of arbitrary circles there. And if you wanted to, on every frame, draw all the 10 circles, then you would have to remember the circles that did not change and then change only the things that did change. So you have to keep track of things that did not change also. So what retain mode does is that it manages a tree of objects for you, where you can only change the thing that changed. And then you can just draw the tree as is. So it's basically an extra layer of state management. And now we're back to the persistent thing that we had earlier, where this is a higher level thing. This is at the tree level rather than a pixel level. So you're not persisting pixels. You're persisting an entire tree. And then you change only one part of the tree. And the entire thing can be redrawn every frame. So we started with the persistent pixels. We moved on to just refreshing the entire set of pixels. And then we're back to persisting trees, just at a high level. So we're moving up in the abstraction, right? So that's where that most graphic, low-level graphic libraries are. If you had to do some kind of OpenGL programming or any kind of UI widget programming, you would be in retain mode. You would just populate a button onto the screen. And you would be able to interact with it. I mean, you don't have to manage it unless you want to change it, right? So everything is. And especially DOM is retain mode. So you just display some DOM on the screen. And then you can change the things that you want to change in response to callback. So retain mode goes a long way. But it has some problems. And these are the hard problems about UI. We are finally at a place where we can think about what the problems are. These are still unsolved. People are trying to solve them. No one has the perfect solution for it. So the biggest problem is reasoning about state transitions. When you have retain mode and you have, tell me if this sounds buggy to you, right? We have a giant mutable global state variable that gets updated by asynchronous callbacks randomly, right? Do you think anything could go wrong with that scheme, right? And that's the way we've been building GUIs most of the time. Like, till five or six years ago, everyone did things this way, right? And I'll tell you what changed like a couple of years ago. So that's the reasoning about state transitions. When did my state, my DOM element, change from one state to the other? It's very hard for you to reason about. So that's where bugs come in, right? And then you also want your UI definition to be composable. So you want to be able to define some components which are independent. And you can reason about those components independently and then compose them together in one big application. So when you have a giant DOM tree, right? How do you separate things, right? So that's a problem. Some architectures like MVC and I'll try to solve it. Like jQuery used to be pretty popular and basically with jQuery, you define a component that handles only a part of the tree, the DOM tree, right? And it's responsible for updating it and communicating with other components and things like that, but it was pretty ad hoc. For example, there wasn't a good story about how do you communicate with other components, right? So you don't know when you're getting something else from some other place, right? So it was very hard to reason about that. And mostly with functional programming, this being functional, the biggest problem we have is reasoning about things, right? So we want to have a system which, even if it's slightly more difficult to use, we want to be able to reason about it so that's much easier to refactor. And we know that there are no bugs with it. So then a couple of years ago, people started coming up with VDOM, right? Which is, I think React pioneered it, I'm not really sure if it did, but it came up around the same time where you basically are back to an immediate model, like retain mode wasn't working out for us. So we are building an immediate model on top of it where instead of changing things in a mutable shared state, you basically re-render the entire state every time, right? That's what VDOM is.  So it's not exactly every frame, but you can think of it like that on every change, every event that happens. And React or virtual DOM is responsible for making it efficient, right? Because you need retain mode for efficiency. So VDOM allows us to go back to the immediate model. And I'm gonna argue that the most natural way of writing code is the immediate model, even though most UI libraries use retain mode, right? So Conquer uses something much more similar to an immediate mode of drawing stuff. Any questions so far? I'm gonna move on to, okay. So while writing Conquer, I basically took whatever I thought was great about existing UI libraries, right? So React has only two good things about it. And these are these two things. And they are functional views, which is basically the immediate mode that I just spoke about where you, a view is basically re-rendered conceptually at least on every frame or every event update. So that's called functional views because you get an event in and then you re-render your entire view without thinking about the state of the view that was there earlier, right? You just assume that there was, you don't have any shared state or safe state that you need to worry about. So it's a functional view. And React also has something new, which is component hierarchy, where you basically define a component, let's say foo, and then you can use it inside a larger component, right? So it has a nice way of doing that. So I wanna show you examples of both. So a functional view is basically just this, right? So you have a local state. This is specific to a component, which is the count of how many times a button has been clicked. And then you just render the button every time the count changes, right? So you're re-rendering the entire button. You don't care about what the earlier count was. Every time you render, you basically return this button thing with the new count as the contents, right? So this is a functional view. And then you can see that you were attached to an event handler that calls this mysterious function called setStake, which eventually calls render again. So it triggers render when you do a setStake. And then it gets a new count. And then you can have nested components where if you have a class called toolbar, it can basically reuse another component called toolbarItem. And it doesn't have to worry about plumbing things, right? You can just use it. One thing that it does need to care about is that how does communication happen between parent and child? So a toolbarItem may need to signal to the toolbar that it has been clicked so that toolbar can update its state for something. So the way React does it, and there are maybe other ways of doing it, but this is the most functional way of doing it, is that you pass a callback as a prop to the inner child, and then the child is responsible for calling the callback. So it's still callbacks, but it's slightly more principled, right? And when that callback is called, the parent component is free to do anything at once, right? And call setState again. So we've seen setState, we've seen callbacks. It's, these are all mysterious functions that are very imperative in nature because what you have is after you call setState, nothing else executes, and effectively some global loop takes over and calls your render function again. So your rendering is pure, but your setState and your callbacks are impure, right? So that's a big problem with React. And of course, even though we have minimized state, but we still have localState within a component. So state is not good wherever you use it. So to solve some of those problems, basically there's this language called Elm. How many people are familiar with Elm or heard of it? Okay, quite a few, but that's good. So the selling point of Elm of course is that it's a pure functional programming language, right? With types, strong types, algebraic data types, right? So that's the best part about Elm. But another thing that it improves on the React model, it still has a virtual DOM, but what it does is it refies the actual action that gets sent. So your view now does not call this mysterious setState function. It instead returns a data type that represents the action you're supposed to take, right? So in case of our previous example, where we had a button which shows a number, which gets incremented every time you run it, what the view can do is that it can return an increment data type. Is this syntax clear to everyone? I was hoping that it's not very complicated, even for people not familiar with Elm. So this is the view at the top where it shows a button. And again, we have an onclick event handler, but instead of calling setState, it specifically calls increment and passes down an address, which is like a pipe, right? So it's not calling a mysterious imperative function, it's doing something specific. And then you have an update function that is a pure way of managing your state. So the update function gets called automatically. So there's still some magic happening in the background, right? But the update function, what it does is it takes the action that was passed by the view, and then it changes your model in response, right? So you have two pieces of functional components there, and the plumbing between them is still a bit of a magic, but what this allows us to do is reason about the state transitions, right? Because every state transition will happen through the update function, and it will be through a specific concrete action data type. So you can inspect all of them, you can see what components and what action data type at what point of time.  I'm not gonna go into that, but there are some videos and stuff on the web. But yeah, so this is the, this is why we use Elm, and again, these are the good things about Elm, so they are in Concur as well, right? So Concur is based on functional programming languages. It has strong types, algebraic data types, immutable data structures, and we use all of them. Some of the problems with Elm are apart from the one that I just said, which is that there are some magic bits to Elm, is that it's crippled. So it's a functional programming language, but it doesn't have some of the better parts of functional programming languages, like type classes. It doesn't have monads. I don't know if that's a positive or a negative. So you run into the lack of these pretty quickly. So it doesn't scale, right? It's the same scalability problem. If you're building a complex application, you have to do a lot of plumbing. There's a lot of boilerplate to work around the lack of these things. Like state monad is a great way to manage state, and Elm can't use it. So conquer allows state monad. Conquer does this, but better because it has monads. I don't wanna show you. Okay, finally, instead of virtual DOM, there's another way of solving this problem, and there are probably more ways that are out there that I don't know about, is FRP, which is Functional Reactive Programming, right? How many people have heard of Functional Reactive Programming? Oh, great. How many people have worked with some form of Functional Reactive Programming? Oh, still quite a few, okay. I'm happy about that, okay, great. So with FRP, basically, what you do is, you have Retain Mode, right? Which is a huge ball of mutable state, right? And you want to be able to reason about the transitions that that state takes place, right? So one way to do it is ignore the transitions, do what Elm and React do, which is just re-render the entire state every time. What FRP does is that it lets you create a graph with explicit dependencies between parts of the state, right? And it has concepts of time-wearing values, which are called events and behaviors, and it allows you to combine those time-wearing values in different ways, and then plug them into the graph, right? So for example, a simple example. Actually, I'm gonna show you an example later on, sir. But the concept is that you create a graph, and then you just let it run, okay? So you're kind of punting on how do you manage the state transitions, because you manage the graph, and that is your logic, and then you don't care about state transitions, right? So it's like a higher-level way of working with state transitions. One of the FRP libraries called Reflex that I've used in Haskell, it also uses monadic layout, which for some use cases is pretty great. So it allows you to render components, compose components together using monads. But it has some problems that I'm gonna show you. So yeah, so these are the FRP primitives. Basically, you have events which are things that take place in discrete points of time. So you have, for example, button clicks. So a button click will only happen at some specific points in time, and then you have behaviors which are things which always have a value at any point of time, right? So for example, system time. You can ask for the current system time at any point. So these are two primitives that you have, and then you can combine them using combinators. So this is just a sample of the combinators we have. You can convert an event to a behavior, right? So can anyone take a guess at how would you convert an event to a behavior? So if you have, for example, a button click, right? Which only happened at some point of time, and you wanted to get a continuous value out of that, right? So how would you do that? Right, but so the problem here is what should, at the time that the event fires, then you have a value. But what about the times that the event is not firing? So you need some kind of a default value to start with because the event has not currently fired, right? So hold is a way to convert from an event to a behavior. What it does is it takes a default value. That's the starting value. At the time you call hold, this is the default value that the behavior is gonna have. And then whenever that event fires, it basically updates the value that is returned by the behavior. So it's a very logical way of composing things, right? So you can convert an event to a behavior. You can convert a behavior to an event, and it's appropriately called sample. Basically you can think of it as sampling a behavior which has a value at all points. And you sample it at some specific intervals and you get the value there, right? So it requires an event also because that event, the second event, event B here, represents the points at which you want to sample, right? So it's a way of composing behaviors and events together. So you have a behavior which is think of it like a graph with a continuous line on it, right? So that represents a behavior. And then at specific intervals that this event fires that you've passed and then sample will just plug the values out of that behavior at those specific intervals. And it returns like this tuple of the value of the event just so we don't lose any information. It returns the value of the event also, which is B, and it returns the value of the behavior at that particular point of time, right? So, oh, I probably should have mentioned an event A is basically an event that has a value of type A, okay? So A could be, for example, an integer or a string or any type, right? Same with behavior. Behavior is a behavior of type A, right? So you can compose things like that and then you can combine multiple events together. So if you have two buttons and you have events that represent each of their clicks, you can join them together. So now you have an event that fires every time any of the buttons is clicked, right? So you can combine them together like that. Similarly, you can combine behaviors. And this is how you would use it. So if I wanted to have a button and some text, and the text gets updated from not click to click, every time you click the button, right? So this is how you would implement it. So this is do notation. How many people know about do notation? Less than I had hoped. So do notation is like imperative programming, right? But this is in functional programming languages. So what you have is basically, you have a do block, which is like begin and end, or you can think of as a function body. And then it does these things sequentially. So here it's creating a button and getting the event out of it called clicks. Now this event fires every time the button gets clicked. And then it's creating a text, but the value of the text is a behavior because think about when you wanna display something on the screen, you need something to be displayed at every point of time, right? It's not that it should appear only at certain intervals, right? So a text takes a behavior of string, right? So you pass it a behavior of string and it takes the responsibility of keeping the text label updated with the value of the behavior. So the way this thing works is that it shows a default value of not click. As I said, hold takes a default value. So the default value is not clicked, but then it converts, it takes an event called clicks and then it converts that to a behavior. So every time that event fires, it basically updates the value to whatever value was returned by that event. Now clicks does not return any useful value because a button clicked, yes. Clicks, yes, exactly. Yeah, yeah. Oh no, so these are lifted values. These are not primitive values. Yes, it does, but you need to lift it. So you can say lift unit, right? So it will lift it into an event. It's not really lift. I don't know exactly what that function is called, right? But there's a function to lift it. Oh, you mean if I replace clicks with something else? Yeah, oh, but what's important is the time at which it fires. So if you replace the clicks called here entirely, then you've basically broken the connection. So it will never know what time the click was done, right? So yes, exactly. Exactly, exactly. So you have a sequential set of statements. Each statement can potentially create a UI element and get some events or behaviors out of it. And these are basically time-wearing values, right? So, and then you can use this time-wearing values. You can compose different time-wearing values together and then pass it to a different widget that uses it to display its contents, right? And that's how you build a graph, basically, with FRP. Another thing here is that clicks does not have a useful value. So we basically map over all the values that clicks returns. So instead of returning unit, which is like a useless value, we return a string called click, right? So this is the syntax. It basically is an anonymous function here, which says that I don't care about what values return by clicks. I just want to, I always want to return the string clicked, right? So, yeah, that's a short introduction to how FRP works, right? Basically, you create this graph and this is like a high-level description of what should happen and then just let it run, right? The good things about FRP are that it gives us the concept of returning things from widgets, right? So a button returns a time-wearing value that represents whenever it's clicked. Text does not have a useful return value because it's just a label, it doesn't really do anything. But potentially it could also have a click handler if you're in a webpage or something. So it could also return an event. So that's one of the things that's in Conquer also. You can return values from widgets. And the other thing is that all of these widgets are functors so you can map over time-wearing values, right? So you basically are, you can change the value that is returned by an event or a behavior or a widget. So those are two things that are in Conquer as well. The problems with the FRP is that it's slightly more complicated, right? I'm sure lots of people here did not understand that sample of code. So it's difficult for new people to get started with. And it also turns out that it has, in my experience, an unpredictable complexity curve. So I've built large applications with the reflex. And I was just getting started with it. So it might be, some of it might be my inexperience, but what would happen is that if you want to refactor some things, then suddenly from a simple piece of code it will become very complex. So it's not a linear curve. It's very unpredictable. In some places it's linear. Some places it's exponential. And it's hard to know when that will happen. And then it uses monadic layout for, it uses monads for layout, which is, I think, an oversight. Layout is not monoidal. It's not monadic, it's monoidal. So basically layout is a way of composing multiple elements on the screen together. And monads should not figure into it. You should be able to take a widget, take another widget and put them on the screen together without thinking about monads, right? So it uses monads for widget composition, which I think is complicated and it has problems. And the place where it should provide a monad, it does not. So monads are good for sequencing things. So state transitions should be monadic, but it does not have a monad for that. It instead uses those time varying values that I spoke about. It does not have composable widgets. You can compose events and behaviors together, but not widgets, which is a problem. And if you have a lot of nested stuff, then sometimes it becomes too complicated, right? So which I already spoke about. So yeah, so let's come to Conquer. It's open source, so you can get it at GitHub, right? And it's also, this particular version is written in Haskell, but I also ported it to PureScript and there's also a JavaScript version. You can find all of them there, the links on this page. So in building Conquer, I only use the freshest ingredients that I could think of. Conquer is pretty new. It's only a couple of months old, right? So I would love feedback on this, but basically it's a strongly-typed functional language. So PureScript and Haskell both are great for this. It's a DSL for functional views. It really builds upon React's functional views, uses virtual DOM, and it takes that and builds upon that. It has components, but it does not have mutable state. It has no callbacks. Everything, communication between widgets happens not through callbacks, but through a monad, right? So it's a sequential way of getting things out of a widget and passing it to another widget. And I'm gonna show you examples of that. So no callbacks means that it's much easier to reason about, and it has three variants right now, and I'm always thinking of porting it to more languages. The JavaScript one, obviously it's not a pure functional programming language, but I think the JavaScript version also worked out great. It uses async generators. So yeah, so I mentioned earlier that we want to do things with as few tool tools as possible, and those tools should be orthogonal. So there are only two things that you need to know about in order to use Conquer. You don't need to know about monads to use Conquer, right, so there's just two things, which is when you compose widgets together, they are monoidal in the sense that you can append two things together, right? That's it, and then when you do a transition, so it's monadic, but what that effectively means that it's sequential, right? So you basically compose widgets to create a view, and then you transition to another view, which has again composed widgets in it, right? So that's the model you need to keep in mind, and this simple model goes a long way, right? From simple applications to very complex applications. So a widget basically is a very generic thing. It can have different types of views. Typically we'll use HTML for web views, but I envisioned Conquer can be used for desktop applications, or it can also do server-side rendering, so then you won't have HTML. You would rather generate a string that has the HTML content in it. So you can change the view depending on what backend you're using. Right now there are two backends, one is React-based and one is virtual DOM-based without React. Both of them use HTML as the view. And then a widget needs to have a return type. As I mentioned with FRP, you have things returning from a widget, but these are not time-wearing values, these are the values themselves. So a button in Conquer has unit as the return value, but it fires only once, effectively, right? So the button gets clicked and then it returns a unit. That's what really happens. And then it has a simple DSL for DOM elements. So text label would just be, it takes a string and then it displays a text label on the web page. As I already showed you in the Hello World example, this is the Hello World of Conquer. And then you can nest it together using arrays. You can see that lists are great for appending things together. So if you have two lists with some arbitrary widgets, you can append them together in a larger list. So that's why I use lists for DOM elements. So here you have a div with some properties. It has a class called header. And then I have a list of widgets that go inside that div. And to create this list of children, you can use list append, right? So you can get children from two different places and append them together. That's the point of monoidal layout. And you can wrap things together. So as I showed you, the div here wraps two text widgets. Each of these is separate independent widget. And then you can take the text widget and put it inside a button. And you can get this button. If you wanted to put two buttons, then again you can wrap them inside a div and you have two buttons just like that. So it's a very simple DSL for creating HTML. And you can have two buttons here like that. If you wanted to compose them vertically, then you can basically wrap them individually inside it. So what I wanna show here is that you can nest it as deep as you want.  And till that point, it's fairly similar to React. But it does event handling in a different manner. So it's not really set state and callbacks. The way it does it is that every widget, and again, this is similar to FRP. Do notation, you have things that happen in the sequence. You have a button and a text, right? But what the button does is that when it gets clicked, effectively the button disappears from the view in conquer. And then whatever happens, whatever widget is next in the sequence, that gets displayed. So this does a fundamentally different thing from the FRP example. Even though the structure is the same, you have a button and then a text, right? But with conquer, the sequencing is used for transitions between widgets. So you can show a button and then as soon as the button emits an event, you move to a text label display, right? This is pretty fundamental to conquer. So is there anyone who would like me to explain this more? I'll come to that, yeah. So yeah, but if you don't want the first thing to persist, you can just move on to another widget. Yes, yes, yes, exactly. Yes, yes, exactly. So I'm gonna answer both, right? So the same concepts apply to different kinds of events also with different data types. Return types. So yeah, it's in one of the following slides. Okay, so yeah, so okay, so what you have is this sequential widget composition and the way this widget composition works is that anytime an event fires, the entire widget disappears, the new widget comes in and that works in a nested format also. So if you have a div that has a button inside it, as soon as the button fires, the entire div disappears, right? So the entire UI that's nested around that event handler, the entire thing disappears, which seems kind of strange, right? But so if I have a button and I click on it, the button disappeared and it showed a text in a button.  This also shows another feature where you have communities like forever, which basically don't let this entire thing end, it just keeps on running it again and again, right? So after the second widget ends, it just goes back to the first one again, it's like a loop, right? So you can, these are very easy to define, you can define them yourself. So that's the event model with Conker. The other thing that it does is that while you're transitioning from one view to the other view, that's a great place to have effects. So Conker has great effect support. You can do things like block stuff, you can use it for debugging, you can use it for bindings to another JavaScript library, for example, FRP is not that great for bindings because you don't have a clear sense of transition.  And with Conker, there are specific places where you have those transitions so you can put effects there. It doesn't affect anything in the view. So this is how you would define forever. It's basically just, given a widget, it runs the widget and then when it ends, it just calls itself again. It's like a tail call, right? So you don't need to understand the syntax completely but these combinators are very easy to define. So this was your question, right? So if you have multiple buttons with different data types, here is the same data type but I'm returning different values. And the way I'm returning different values is I'm, this dollar syntax is basically mapping over the event that gets returned, right? So this basically has two buttons with event handlers for each, right? When the button gets clicked and button event handlers generally return unit which is no useful value but I'm using the mapping to return hello from the first one namaste from the second one, right? So to answer your question, if you have two different data types you would map over them to make them the same data type. So if you have like int and string, you would probably put an either on top so you have left int, right string, right? To make it the same data type. So, and that has to be done only in this specific place and then you can take it out and then remove the wrapping. So the rest of the code doesn't have to deal with that wrapping and this shows that the widget itself is also can be mapped over and the event handler itself can be mapped over. So there's a subtle change here. Here I'm returning hello from the event handler and here I'm returning hello from the entire widget. It's the same thing. It does the same thing, right? So what it does is if you click on hello, it says hello sailor. If you click on namaste, it says namaste sailor, right? So that that's how you define it. So, I must skip over that. Okay, so this is a good example of what you said where you have an on change and you have an on focus, two separate event handlers, they return different things because on change has to return the changed value of the text on focus just says that it's focused to its unit and I wrap it in a data structure that abstracts over the differences, right? So change returns a string and focus doesn't return anything useful. This conquer model is generic enough to implement Elm architecture in it, which is very simple. So basically you define your state the way it is and you define your action data type just like in Elm and then when you compose the widgets together, you're basically doing it using conquer's model but the first part displays the entire view with the event handlers. This is like Elm's view function and as soon as any event handlers within this fires the entire view gets removed from the view, right? From the webpage. So, but then you have the value of that event handler with you, which is like the action from Elm's model and then you can use the action to update your state and call itself again. So here I'm, so I used the action whether it was whether you clicked on the remember me checkbox or you clicked on some text box or did whatever and then I call the same widget again with different set of parameters to represents that change in state. So this is effectively Elm's model and since it uses virtual DOM which is the same thing as Elm, so it boils down to the same thing in the application and this is what it comes down to. I can, every time I type something it fires an event but then it changes the value of the text box, right? But it doesn't end the entire application. So this was your question, right? So you want a persistent checkbox and text widget there. So how do you do that? So every time this event fires and it's about to be removed I just call the same widget again with the same parameters and it just gets displayed again and React makes it so or virtual DOM makes it so that you don't see the transition, right? So it just calls the same widget again with a different value of the text box and it displays that only when I click on submit does it actually end and update the text on top, right? So doesn't update it every time I type something here but it updates it every time I click on submit, right? So these applications are easy to build with a conquer and then because it's a monad you get like cool things like what if you wanted to show a list of forms and get all their values out in an array and this is sequentially so you should form one, get the value out, form two, get the value out and so on till the very end and then at the end you want a list of all the values that came out. So that's simply traverse. So you traverse over a widget and you get that behavior, right? So this scales, right? So this is the scalability thing, right? So you can use whatever monadic combinators you want to use and it'll just work, right? So persistent widgets, I also have another solution called signals which is like poor man's FRP, right? I'm just gonna take two minutes to quickly go over that. Basically a signal is an abstraction over a widget and again this is implemented in like half a page of code, right? So it's not very complicated on top of widgets but basically it's a widget that recursively calls itself. It's a forever looping widget and then signals provide a way to compose forever looping widgets together, right? So how much time do I have time? Okay, perfect, okay. Okay, so I'm almost done with most of my stuff but I'll leave some time for questions after that. So yeah, so with signals you can write a very similar code as what we had earlier but now it's a signal and all these divs and buttons, all those combinators that you've defined, I made them all generic. So they can be interpreted as signals or widgets, right? You just write them and depending on the type signature it does the right thing, right? It makes them a signal or it makes them a widget, right? So you don't have to change your code but now what has happened is that every time you click on a button it doesn't disappear from the view, right? Because it's a signal, it's a forever running widget. It, one good thing it has over FRP is that the return value from a signal is not a time varying value, it's a normal value, right? So you can, you don't have to deal with the complexity of joining events together, joining behaviors and events and doing those things. You can basically get a value out and then you can do pass it to another text label there and it just works regularly, right? You can just, you can have an effect that logs it as string and it will just work. Okay, so we have signals composed just like a regular monadic thing. So here I'm, I have that hello widget. I can run it twice and both of them will be on the screen at the same time because this is, this basically gives you what FRP gives you and it gives you that monadic layout which has its own problems. So signals have the same problems. So, but we also provide widgets to get over those and then signals can be easily converted to a widget by just calling dine. There's a function called dine and it becomes a widget now. It's all magic, right? So, and then what if you traverse over all signals instead of traversing over all widgets? So because signals are persistent, when you traverse over a form, let's say a hundred times, it'll show hundred forms in the same page and then you can fill all of them and then when you submit all of them it'll show you the result as an array, right? So signals have different semantics but it's the same code. The same code works for both signals and widgets. That's all I had. I wanted to show you some life code like this slide deck is written in conqueror. I can change code right now and it just immediately changes. But unfortunately we don't have a lot of time. So any questions that I can answer? Thank you. Thank you very much.


Hi guys, welcome back to my channel.  So I'm not like, I don't know, talk about the next time. Anyway, got my makeup bag here and just going to get started. It's so convenient to like have such a big makeup bag now. This is like my first little stony clover piece and I'm excited about it. I can fit like literally everything. I have extra band-aids, my dry shampoo in there, everything. So starting off, I wanted to just like shout, not like shout out, but like check the link in the description box to a GoFundMe for one of my old friends. His family could use some support right now. Like I don't wanna like, I don't know all the details or anything really, but you can just read on like the page and everything about like what they need help with. But I just wanted to shout that out just in case you guys wanna check it out and like help out with their family and what they need. Or you can just share it to like your social media pages and everything. That would be great. I don't know, I feel like with a, some sort of a platform like this, I want to do everything I can to like help and stuff. So just wanted to start that out, start this video out with that. In this video, I'm just going to be talking about when I started my period cause I think that that would be like such a funny story to like share with you guys. I don't think I've ever talked about it on YouTube. And also YouTuber drama that like, well I've never really been in like full YouTube drama, but it's just like a funny story. And honestly, I don't think, I hope the girl doesn't like hate me, but I mean, anyway, I just wanted to like share this stuff because I would love to make like full videos about it, like full sit down videos, but I don't think they're long enough to actually make a video. Like it would be five minutes probably. So I just decided to do like a little get ready with me chit chat and I'll just like tell you these stories cause like I just find them to be like funny and everything. I'm gonna start off with like the time I started my period cause I think that's the funniest one. And that was like in my notes app to film. So I was, I think I was 12. I think I was 12. So I was 12 years old and I danced a lot. Obviously. So like every Saturday I would have like a rehearsal for competition cause I did the dance competitions and everything. Okay. So I would always go dance like every Saturday because you know, we had to like practice learn the dance, like all of that stuff at practice. And there was this one practice. This is like a side note just cause I'm still doing the concealer, but there was this one practice where I think I like are totally overdosed on cold ease because I was like sick and I wanted to like go to practice still. So I took like probably 12.  It's kind of like mucinex, not mucinex anyway.  I know that's like a complete side note but I just remembered that because I think it was the same year cause there was this dance called Egypt and like we were, it was like Egypt and we had like this pyramid prop thing. But anyway, it was the same year. That's why I thought of that. So it was at one of those rehearsals and I didn't have any symptoms. Like I didn't have any cramping.  I never really got cramps as a kid and everything. So I did not understand like what I was going through at a time because I didn't feel anything. And this is at, for those of you who are watching this that actually like no, I don't know some people in real life watch these which is crazy because I always forget that people in my real life watch these. So for those of you who are watching this this was obviously the old location of the studio up by I think the road was called Vanguard. So this was there. So we were rehearsing this dance and there was this scene, scene. There was this like part of the dance where I did an aerial across the floor. I don't know if it was like the past section it probably was like, I don't know. I needed to get to the other side of the stage and I basically just did this aerial because my teacher was like, oh, you're gonna do an aerial across the stage. And I was like, okay. So I don't know if that part was like actually kept in. I know this is not important but I'm just babbling on and do the aerial across the stage and then like I feel something. And I was like, and it wasn't that big. Like my, obviously my flow wasn't that huge because I was a smaller person. I don't know if that has anything to do with it but I felt something but I didn't like check it because I'm like, oh, it just might be like sweat or whatever cause like, you know, you get pretty sweaty. You get pretty sweaty just dancing in general. So like I didn't think anything of it. I didn't have any, like I never got any symptoms or side effects when it came to like my period. So I don't know. I just went about my day. But obviously I had to go to the bathroom. Obviously I went to the bathroom and go in there and low and behold, my period had started. And I literally just remember putting paper towel, not paper towels, it was the toilet paper. It was toilet paper in my underwear. And I had to obviously like go back to the rehearsal. So like that's just what I did. And then after that, the rehearsal ended, I changed the paper obviously cause I think more came out, you know, obviously. So I was like, oh, this is weird. And so well, throughout the day, I would change like the toilet paper but I didn't have like anything with me, obviously. Shoo, I forgot to do the blush. See, this is what happens to when I like talk and do things, can't focus. And then I just get all sidetracked. Okay, I'm not gonna try to do a lot of makeup. I just wanted to be doing something when I talk to you guys because I don't know, I find it more interesting and like more, you know, girl time, just like chit-shining. Anyway, so I changed the paper throughout the day but then finally like the practice ended. And then I told my mom like, hey, I think I started my period. And then I just remember, obviously like I showered and then I showered and we went to like a CVS or like Walgreens, some type of drugstore. And we got pads and I got the ones with like the wings which I still use to today. So shout out to always not sponsored. So we get that. And then it was December 15th, if I'm remembering correctly. It was definitely in the winter time because like it was colder.  And I was like, okay.  So I just found that to be like kind of funny. That was another thing that like I distinctly remember like having to call my grandma and tell her that I like started my period, which I find to be like so funny. That was pretty much the story time of like how and when, well not how, but like when I started my period and learning how to put in a tampon. Oh my gosh guys, like that was like an experience.  So then I tried it and nothing wasn't that bad but then I got like the lecture about toxic shock syndrome and like whatever. And I think it was Sherry, but she was like, you should totally wear tampons like for when you go dance. And I was like, okay. So I try it. Okay, now we're ready to do the powder. Okay, so then Sherry was all like, you should wear tampons for dance cause it'll be like more comfortable for you and all this stuff. And I was like, okay. So I try it and I still to this day, like I don't know if I use like the raw ones or whatever. I use the sport ones. So I don't know, man, but I remember in ballet class. Okay, we were doing those like romplies and like whatever you do in those classes. And then I go to the bathroom cause I don't know why I always had to pee in ballet and it was probably cause like it was so boring. I go to the bathroom and guys, like there was just like blood. And I'm like, I knew I had a tampon in and I'm like, this thing is not working. And from that day on my camera battery freaking died on me when I was talking about tampons. But from this day on, like I just don't wear tampons because I don't feel like they work. Maybe I'm wearing the wrong versions of tampons. But I swear, like I use all different sizes and like different types and like still not that they don't work, but it's like some leakage gets out and it's just like what is going on? So I don't really use those. I only really use them in the shower because I don't like to see fluids come out in the shower. So I wear them for the shower and then I wear them for the beach or pool or whatever. But that's really like the only time I wear tampons. The rest of the time I just wear pads because I'm not really a big fan of like, I don't want to try the Diva cup. I don't want to, I don't know. And I don't mind the feeling to be honest. Like it's not that bad. And since my flow isn't that horrible, like especially now with like birth control and stuff, it's not that big of a deal. So I just, you know, I just do my own thing and just wear pads when it comes to like my period and stuff. I think now, oh my gosh, I'm like missing, this is why I can't like multitask when doing the makeup or anything. Because I always just like forget like what's going on. But then again too, like I never do my makeup because I don't know, I sit in a dark room all day. And guys, oh my gosh, I've had this for forever and I've hit pan on it, which I need to like get replaced or whatever. I need to get some more eventually, but maybe I'll get some today since we're going to the mall. That would be a good purchase. Okay, so moving on to like the YouTube drama, I guess I don't know, this is not like actually drama or whatever, but okay, so there was this girl that I met kind of through YouTube, just like naturally, right? And I don't think she like posts a lot anymore.  I think she puts up like good quality stuff. And so we met up and we met at this, at Playlist Live actually and she was like moving here or whatever. And I was like, oh, that's cool. But she was like kind of younger than me. So I mean, we're just at different like stages of our life. And we meet up this like one time to like take pictures and she was like really cool. Like I got to meet like some of her, I think college friends, like I don't really know too much. I don't know how really she knew them. I think they were her college friends or whatever. And we had a good time. We took pictures and stuff. And then after that, like I obviously like wanted the pictures cause she had this like really good DSLR camera, which I had a good DSLR at the time, but it wasn't like hers cause hers was like, you know, one of the really, really good ones like with a good lens. So like me, just like wanting the pictures, like I was like, hey, could I get the pictures? And she was like, yeah, I'll send them. And like I never got them. And I was like, so then I texted her again, I think and something happened with her like SD card or something with the memory card.  But then like after that, like I've never heard from her again. And I'm like, oh, that's awkward. And then she unfollowed me on Instagram. I think she still follows me on Twitter, but my Twitter is like all private and stuff. So we definitely agree on like things that she like shares and stuff. But yeah, she, I don't think she followed me on Instagram anymore, but I still follow her. And I still like hers.  And I understand that like, well, life happens and we were like in different like stages of our life in a way. So I'm not like mad about anything, but yeah. And like then I remember texting her like in 2020, like with this TikTok, I guess. And then she like never responded. I'm like, okay, well, I guess that's it for that friendship, whatever. Maybe she deleted my number. Maybe she got a new number. Who knows? Probably not, but I mean, I don't know. I just find it to be like so funny. Yeah. And to this day, I still have never like gotten the pictures. It's okay though, like, but that's like the closest like huge YouTube drama drama or like a conflict that I had with someone online. So I don't know. I just found that to be kind of funny and I wanted to share that, but I mean the story is not juicy or it's not big enough to like make it an actual video. So I just thought I would throw it in here to share with you guys because I don't know. All right, now I'm gonna do the brows. I swear guys, the brows are always just so hard. It's okay, I'm getting a little better at this.  So as you guys can see, I could definitely not make like full videos out of any of those things. Like going back to the girl that I had, it wasn't like a falling out, but just like, I guess a growing apart, different ways. I wish her nothing but the best and I hope her career goes well. I must say that this lash gel is like so fun to put on. I think this is like one of my favorite parts about doing my makeup because it's just so fun putting on. So I was watching one of Carly Cohort's vlogs. I really enjoy her videos and stuff. She is a cheerleader and she was talking about like this little serum that she has that she wears and I wanna try it because it just is a very like light face makeup and I feel like for every day, maybe like for work or whatever, I could just wear that instead of like actual foundation. I feel like trying it. All right, so if you guys watched Stranger Things 4, let me know what you think of it cause I would be very curious to know your thoughts and opinions. I like the season a lot. I think they did a really good job with it. I'm just like dying to know the other two episodes. Like I wish they just would have released it like all at once, you know? Okay guys, this is pretty much my normal look. I went light with the eyes and just, I don't know, but I hope you guys enjoyed this little video and like enjoyed some of my little stories that I just wanted to share with you guys. Make sure to give this video a thumbs up. Don't forget to check the link in the description box and I will see you guys in my next video. Bye.


The urgent union of local government employees, Nolge in Bajosa state, has called on state assemblies that are yet to pass the local government autonomy bill to do so, so that the third tier of government can contribute meaningfully to the development of the country. Nolge president in Bajosa, Kormit Apoos Ekyara, says, until this is done, there will still be room for state governors to temper with council's funds, which will in turn hinder development at the grassroots. Our correspondent, Jesse SAE, has details. The campaign for local government financial and administrative autonomy was championed by Nolge with support from civil society organizations and social development advocates in order to enhance good governance at the grassroots. The bill has been passed at the national level and transmitted to the state assemblies, but for it to become a law, there must be a concurrence by two third of 36 states, and this is where the problem lies. By SICA to do the needful, notwithstanding, Apoos Ekyara says the councils enjoy financial autonomy. Before you cannot see tangible projects, but for now you can see tangible projects because they don't interfere with the fund, they don't touch the fund of the councils. She-men are liberty to do whatever project they want to do.  Like, you know, what local government rules were constructed. If you go to certain issues, if you go all around the council, the eight local government areas, because the funds have been managed by the councils. We have financial autonomy, we have administrative autonomy. But all what we are pleading now is, since we are practicalizing it, let the alteration be done in the constitution so that we should be fully autonomous. He also gives reasons for the industrial harmony in the state. The governor, when he came on board, he said worker salaries will be paid once the jacket is released, as from twenty-third to twenty-fifth or twenty-six salaries will be paid. And he has never failed. And once you keep workers welfare, first land charge, you see that there will be this high industrial harmony. And that is what is happening here. Promotion has been released, promotion has been implemented, real speed. But our neighborhood states here, since they came on board, no promotion has been done. Areas has not been paid, no increment, no notice of workers are crying in our neighborhood state. But by us, our state will give the governor 100 percent. The Malge presidency believes that the bias of state has to assembly. We vote in favor of the bill. Just see, you see, for plus TV news. You get notified about fresh news updates.