Okay, great. So let's get going with our next talk. This is one of the longer talks 45 minutes Which will go by a blinding speed because our next speaker is you who the cats the man who needs no introduction So take it away. Thank you So today I'm going to be talking about as you might have guessed the idea behind cruft So yesterday Sandy gave a really great talk about the reasons that we get less satisfied with our projects over time her talk mostly focused on the ways that Using better object models using better object orientation would avoid that decline that steep decline in satisfaction over time And I thought that that was I liked it a lot I felt like to the extent that the problem is poor object design poor Structure, I thought her talk really provided some good tools that you can use to help avoid declining satisfaction over time My talk is about situations where we cannot avoid this declining satisfaction simply by doing a better job ahead of time Sandy told you how to contain the mess today. I'm going to talk about how and when to clean it up This talk is basically about the declining value of code over time when you write a piece of code for the first time It feels great because what the code does matches perfectly with the assumptions made by the code But over time those assumptions change subtly at first and then faster and faster and faster This takes years often and my projects this always takes a long number of years but the graph the gap doesn't grow linearly the gap between The assumptions that were true when you started building your application and the assumptions that are true years later actually grows faster and faster and Year-over-year you're gonna write the same amount of code people write Lines of code that are the same year-over-year But the weight of those mismatch assumptions the gap between the assumptions that you made when you first wrote the code and the reality years Later consumes more and more development time here I have just a projection of the previous slide if you assume that you're getting accelerating more and more and more Assumption mismatch over time You're able to write more code, but the assumptions that were incorrect that were correct in the beginning But are incorrect now eventually catch up with you This sounds a lot like classic technical debt, but there's a big difference you take on technical debt on purpose With enough discipline you imagine that you can eliminate it altogether By thinking about technical debt in sort of in the way Sandy talked about yesterday Or you imagine that you can pay it down you take it on on purpose and imagine that you will pay it down The problem I'm talking about today is more like buying a bunch of rim stock in 2008 and never adjusting it when the company tank and Unlike technical debt Technical obsolescence will build up no matter how hard you try to avoid it. The question isn't how to eliminate it It's how to plan for it So today since I do so much work with open source I'm going to give some examples from the open source ecosystem And I think one of the reasons it's very In sharp relief with open source is that open source works on solving problems very generically And so if a problem is tricky often that gap becomes a chasm very quickly as the generic the assumptions made early on Rapidly fall out of favor. I've given a couple of talks like about things being hard and You might want to watch this just to get a sense of sort of what's going on behind the scenes I think this would be a decent companion talk but the basic idea here is For everything that seems straightforward it seems like I say render and then I render a bunch of stuff on the screen Obviously, it's relatively straightforward. There's a lot more going on behind the scenes There's a lot more assumptions that are building up and that's true not only about applications that It's not only true about open source projects like jQuery or rails But it's also true about your own applications often applications can take on the characteristics of frameworks or libraries over a long period of time So a good example of this sort of thing is jQuery's DOM readiness API and DOM readiness is something where Solving the part problems generically basically means that there's an assumption for every scenario and every use case So it's not just one assumption You know the assumption would be the browser does not provide a way to find out DOM readiness Therefore we will do this hack that would be one assumption and one outcome but actually there are many many different browsers and many many different use cases that people are using this API for which Means that there are some assumptions that state true for a long time like in IE six There is no way to find out DOM readiness without hacks But there are other assumptions that drift over time like in Chrome. There is no way to find out DOM readiness, right? So you end up with a situation where Technical obsolescence basically creeps up on you because for a long time one of the anchoring assumptions of your API Stays the same but the other anchoring assumptions are slowly drifting away So the gap is growing, but there's really nothing you can do about it for a while Rails had some examples of this Security in general almost all this rails assumptions that it made about security the first time we ever built anything with security Just turned out to be wrong, but again these assumptions creep up on you There was a pretty giant CSRF example a few a couple years ago where basically just it turned out that the entire Assumption core that rails was using was just wrong and so obviously when that happens It's sort of game over but there's obviously gaps that start to build up over time in coatings right in Ruby 1.8 there was no coding support and Ruby 1.9 shipped encoding So now the assumptions have changed, but as more and more people move to Ruby 1.9 the possibility of us using the change assumptions to do anything I Guess sort of the the the assumption gap grows But the ability of us to do something about it doesn't necessarily Snap into relief until for some time In ember we have this is sort of my I'm early on I'm early on in that big one in that Big gap so there's things that we're doing like data bindings or how you should build your application structure where today The code that we're writing is still very much in line with the debt with the Assumptions that we're making right so data bindings well, there's no data binding support in the browser There's no object observation in the browser So we're gonna use set and get and so far that's true And it's very difficult for anybody to come up with alternatives But over time that gap is gonna grow chrome is gonna ship object that observes right and we may not necessarily be able to do anything about it right away But the fact of the matter is that the very clean very clear assumptions that we have today which are we have no choice We have to do everything ourselves that feels good today And is a good reason for a whole bunch of architecture decisions that we're making will slowly slowly drift and Again in open source It's especially bad because he really can't you have to wait until they drift where it till you get this giant Chasm before you can actually do anything about it in your app You might be in a better place and that's just a couple of examples There's just a ton of things that every project does that are based on assumptions That's really the core of my talk today is that there are assumptions underlying every decision that you make and the constraints that underlie Those assumptions while they may be perfectly true today and following those constraints will make you happy as a programmer today Once when those assumptions go out of style and those assumptions are no longer true That's one of the main reasons why you as a developer become less happy with the code that you write And I think another interesting thing about open source is that this problem is because worse with really good solutions with great solutions Right with good solutions you can get away with having sort of blah bland assumptions You're a you essentially offload a lot of the assumptions onto your your users So you don't really have to change a lot There's not a lot of the effect of the code that of the library that you wrote that really changes because the user is Responsible for keeping all that up to date But when you have a really great solution something that really takes shoulders a lot of the burden for yourself Something like rails or something like I think ember The end result of that is that changes in assumptions have rapid effects on the ability on that gap right so in rails if it turns out that HTML rendering on the server is no is a bad assumption Then it's not it's not simply going to be oh no problem. You can sort of tweak around the edges It's gonna be it's a it would be a big problem I think rails took some steps years ago to help mitigate this but basically if you or if it turns out client side development It's a bad idea. Nobody is going to do that embers basically game over because we basically took such a big bet and this is sort of a Side point, but a lot of times people don't notice the difference between how much Between a partial and a full solution until the solution itself starts to break down You end up with sort of checkbox oriented featured feature assessments or you're like oh, let me look at this library doesn't have any of these features and There's sort of the reason I bring this up is that I think Understanding the idea behind technical obsolescence is an important part in deciding What you're gonna pick so if you have a project that's gonna be on around for a very long time You need to really plan for technical obsolescence and I think people when they do checkbox oriented feature Analysis, they're not really thinking a lot about okay, so there's this routing feature or there's this data binding feature What assumptions underlie it now? There's sort of I think a big a big objection to a lot of the things that I'm saying here and a lot of my philosophy in general which is you can basically avoid all software problems and actually I Think Sandy's argument is A weak version of this straw man You can basically avoid all software problems by writing one writing programs that do one thing and do it well and Then if something changes if some assumption changes no problem Just remove the little tiny piece of your program that has the violated assumption replace it with something that has better assumptions And no problem that will be great And I think writing good decoupled object oriented software is gonna be a way that you deal with certain problems It's gonna be a way that you deal with some problems But I think that this kind misses some of the mark and I think the reason is that this Sort of this sort of thinking simply moves the complexity to rapidly evolving public API So instead of having the complexity inside of private API is what? Sandy called the Omega mess you end up with a very public and unstable mess and Unfortunately No matter how hard we try we usually don't get these interfaces perfect And so this the idea that don't build any Omega messes ever instead move everything to public APIs and public Interfaces and write one thing that does it well I'm not saying that this is what Sandy said, but this is deaf. This is the straw man objection What this ends up doing is it ends up creating all these public APIs that people who are using the system have to understand So it moves the complexity essentially from edge cases that are inside a self-contained component to edge cases that are now in between all these components And in many cases this problem pushes the integration tax onto the user So the user instead of the user saying I'm just gonna use rails. I'm gonna type render. I don't really care what render does I want to make sure I get something onto the screen Now the user is responsible for saying where do my templates live? How do I decide what template engine to use when I render a template with a partial? How does it know where to find it right? So you may have a very very good interface you may have a path-resolving interface that lets you explain to the to the Template system how to find other templates, but that doesn't mean that there isn't an integration tax that is being placed on the user I also want to point out something that I find interesting people almost never say the entire Unix philosophy And I think it's because it undermines the the point that they're trying to make there over some Overly simplistic point the original Unix philosophy was this is the Unix philosophy write programs that do one thing and do it Well write programs to work together write programs to handle text streams because that is universal interface, and I'm not saying Ha ha I got you node is not about text streams game over what I'm saying is what I'm saying is There has to be the idea of a well understood Well stable public interface in order for the idea of writing small things that do things and do things well to work If you're in a situation where you're in the middle of building something you're in the middle of deciding what your domain is You're in the middle of figuring out what it is that you're building and you try to build these little things that do things well And talk to each other you're gonna end up spending more time thinking about the interfaces between these products and actually figuring out your Domain and early on in a project in the unstable part of the spectrum It's actually very important that you figure out that you make your way to stability Okay, I agree So here's an example so the Unix philosophy works really well when you're working with simple text formats But in this case Even though it works it would be better if there was just an answer in get and in fact That's how get has moved get started off with a very Unix philosophy oriented There's a bunch of text that gets dumped out feel free to do whatever you want with it You can run all these commands But at the end of the day once you get to a more stable understanding of what it is that you're building Having interfaces that say I would like to know give me my branch or whatever works great And I think another point that I would make about this slide is that it also relies on the idea that When you say text of the universal interface, there's actually something implicit there Which is people are you using tab delimited or space delimited or some kind of sensible delimited output If you have something like get which just dumps user-friendly output onto the screen in a lot of cases in order to get information You're not necessarily going to be able to use the Unix philosophy to get what get done what you want to get And so I was thinking about this a lot and one of the I sort of found an analogy in the idea of supply chains and supply chain management So early on in the in the stage of building a car. That's not a real car But early on in the stage in the in the 19th century when they first started building cars people didn't really know what a car was yet and so initially The idea of vertically integrated supply chains the idea of I'm just going to do all the parts myself Ended up being very effective. So it isn't necessarily how it started out But vertical integration really won it won the story early on in the process of building Cars because of the fact that there's the idea of a transaction tax And basically the idea is that when you're not sure when you're not really sure What's happening in between all the steps in between all the pieces of the puzzle? There's a high tax communicating between all the different pieces of the supply chain So don't pay the tax just do it yourself and you could you don't have to worry about Standardizing things you don't have to worry about figuring out how the parts guys are going to talk to the assembly guy You're going to have the Ford specific version of that and then don't worry about having the everyone specific version But over time vertical integration actually does give way to distribute systems this this happens in economics and But when does that happen and the answer is that it happens in response to more standardized ways of thinking about things and a more reliable supply chain, so How does this fit in with software? so when you build Components in software components connect to each other very promiscuously You can be careful about this But the end result especially in an unstable system is that you have a lot of components that connect to each other promiscuously and The point that I'm making here is that every link in this in this diagram represents a transaction cost and Typically the cost early on in a system The burden of this cost is on the end developer right so you end up with you have Sinatra and you have What's that the shotgun and you have? Eurubus as a separate library and whose job it is who ends up being the person that pays the transaction costs for getting all These things together why that that's Ford Motor Company. That's you that's the person that actually puts it all together so What happens over time though is that a lot of these? Connections fade away. We understand more what it means to build a car. We understand more what it means to build a web app we understand more how you want to integrate between a template engine and Rails itself and so a lot of the transaction costs become much much cheaper So instead of there being large transaction costs the cost of thinking about okay How do I integrate rails with Eurubus initially? It's very expensive. You have to think about it a lot eventually becomes rather clear In sort of the way that it became rather clear how you integrate template engine in JavaScript There's a function it takes a context returns a string right that's how it works in JavaScript Eventually that sort of happens on its own everyone understands what's going on and integration gets cheaper But integration only gets cheaper some of the time and I think that's one of the main points that I'm trying to get across here, which is Even though integration gets cheaper it doesn't always get cheaper Which means that if you start off with the idea of why don't we just front-load the whole thing? Why don't we just build standards for every single link on this chain? We'll just say what every single thing is we'll say how you look up templates will say how you can talk to templates We'll say how you render things will say how you respond You're gonna have turned out spending a whole bunch of time building a bunch of Standards that don't end up mattering that don't end up really reducing transaction costs it ends up being Cheaper to not have bothered now rack is a really good example of sort of this life cycle so Early on in the days of rails Basically, this is what an architecture diagram looked like there was rails. It had a bunch of stuff in it and Then there was mongrel which had mongrel rails inside of it and those are basically the same thing So it was basically one giant thing. It was a vertically integrated Supply chain, but why did we do this? I think in retrospect it seems fairly obvious. Why would you not have rack? Why would you not have some sort of standard Java did it Python did it before much before Ruby did it So why in the beginning of this process did rails decide not to do that? and The answer is that the early on in the process the costs of building the standards of thought costs of integrating with third parties Ends up being bore and ends up being bared heavily on the big player So rails would have to essentially build the marketplace so rails have to choose between figuring out what was going on what does it mean to render what does it mean to return a response in Ruby we have to choose between that I mean I wasn't part of it rails have to choose between that and spending a whole bunch of time to build a marketplace of third-party components Now what ends up happening is that there's usually small players So murb was an example of this although murb ended up being a pretty big player There's usually small players that realize it's annoying as a little guy It's annoying as Sinatra for you to have to actually build server connectors to every single thing so one of the sort of side effects that happens early on is that This happened to rack is that people say look there's a de facto standard you rails, please integrate with this de facto standard and This is actually a pretty good bludgeon against an integrated solution So when you start off in the beginning You really want to just go get stuff done build an integrated solution Figure out figure out what the domain is and don't bother to try to figure out what all the integration pieces are But it's very easy and open source for a third party to say hey There's this standard you should really implement it So what happens after that so it's very hard to actually fight back against that So what usually ends up happening is that you have now a ton of standards, right? So a mongrel points the rails entry point points the session middleware points HB security controller actions These are all standards. Everything's a standard and Unfortunately even when interfaces are standardized They're still integration costs and what basically ends up happening at the end if you look at where rails is today is There are some parts of the system Where you really want standards you really want the rails router to be able to route to a synod trap That's a really important thing and so the idea of rack is essentially Very standardized the the cost of adding a new rack like component to rails got very cheap This ended up being a big win But there's other things like how sessions work in rails where rails really pulled back rails said We don't really think that it's a good idea for us to spend significant amounts of time Working with the community to figure out a general session interface because it's costing us and our users a lot in terms of Oh, we realize there's a bug in our session system now We need to go through the entire process of getting a new standard So there's still parts of what rails does that even though Theoretically you can imagine that it could be standardized Doesn't really turn out to be the case And I guess the question that I would have you ask about all this is who pays the integration costs and the answer is never Nobody pays them. They're free. You build a standard and it's free Hopefully in a good world the integration costs are spread out across a lot of users But the short version of what I'm saying here is in rapidly evolving spaces tighter integration improves robustness and That is a contrast to everything should be standardized and I think one thing that's interesting about the whole unix question Is actually it turns out that unix didn't build itself as a thousand people building one tool that happens that happens to work Actually, most of unix's tools are were built by atnt and we're obviously built to work together by people who were who themselves work together Okay, so that's that was sort of a sideline. What does this all mean for software? So what it means for software is Cruft is inevitable when you build something in the beginning You don't know the whole story yet. You don't know what the domain is I think this is as true and open source as it is true in your own personal applications Maybe more in your applications than it is in something like ember or rails So you don't really know what's happening yet And so the cruft is not there because you're not it sometimes it's there because you're not good enough at object-oriented programming yet But often it's not there not because you don't know enough about object-oriented programming But because you don't really know what you're building yet The real world is a messy place There's a lot of assumptions that go into the things that you're building Whether you're supporting ie 6 7 and 8. Are you supporting ruby 1.8? Are you supporting rails 2 3 etc? All these all these assumptions and those are just assumptions about platforms There's assumptions about your own projects as well, right? Maybe you're building a construction management tool Maybe congress passes a whole new construction management regulation and that changes everything Maybe that happens slowly over time and the gap grows Maybe everyone starts using computers instead of using fax machines So in in fact Solutions that you build as part of the projects that you're building are often ugly But again, they're not ugly because you're writing software poorly They're ugly because the assumptions the the people that actually power the solutions that you're building Are ugly. They're crafty Didn't mean to say that people are ugly see previous talk and the cruft that you're building Is cruft that becomes obsolete over time, but it reflects the current reality of the ugliness of the underlying problem Now here's a really sad thing about all this which is that Early on early on When you add cruft you're adding cruft for a good reason jQuery added a lot of stuff early on because ie 6 demanded it But People often respond to cruft in a sort of knee jerk fashion So early on if you're writing a project and you have to deal with some ugly underlying problem You are going to get really defensive every single time someone says that code looks ugly. What are you doing? That's crazy. Couldn't you do something way simpler? You're going to get really defensive about that and the really really sad part is that over time in a project Especially as you have personnel turnover The idea that the cruft is just there because it has to be there becomes received wisdom And if you remember in my first diagram, I showed that that gap grows slowly So in the first two years, this is the right thing to do Everybody should say if there's cruft is probably there for a reason Everybody should say don't touch that. It's probably there for a reason. We knew what we were doing But as years and years go come along You end up with people doing a couple of steps that make the situation even worse So you have in the in the good in a good world Somebody goes and they says what is this cruft? This is crazy.  They go and remove it They spend a day refactoring and then they get a test failure And they say ah in fact this received wisdom everybody says don't touch that they knew what they were talking about There's a test failure. Aha and in a bad case Which has even worse has even worse reinforcing behavior. You remove the cruft everything passes you go and ship a release Everybody freaks out And now you say oh my god after avert and again that just reinforces it reinforces the idea that everybody has that The problems are every code a piece of code is there for a reason the cruft is there for a reason And projects end up developing immune systems if somebody says hey, I want can I spend a day or a week Refactoring this piece of code everybody remembers the last 10 times somebody touched that and they say no Don't touch that code leave that code And this is basically this is what rails 2 3 was like Rails 2 3 was basically a lot of code was there for a good reason But it was there was so much code and there were so many assumptions that built up over the years That were sort of implicit that everyone said don't touch that It's probably there for a reason don't touch that but Over time assumptions change over time The three there's a lot of code in rails 2 3 that was there for ruby 1.8.2 There's a lot of code in rails 3. That's there for ruby 1.8 There's a lot of code that's in jQuery for ie 6 7 and 8 And there's probably a lot of code that's in your app That was there because of some assumption that somebody made good or bad really early in the project that doesn't apply anymore So here's an example from jQuery. We have a dom node and you want to put some data on it Turns out ie is stupid ie has a memory leak that obviously will never be fixed in ie 6 That if you put some data on the dom node and remove the dom node the gc never collects it so So here we try to remove the node. We have a memory leak that sucks So what does jQuery do jQuery says okay, we can put a number on the dom node numbers are don't cause garbage And then we will go and we will create a separate cache that puts a data in that number And then we will make sure that when we go remove the node you always go through jQuery when you remove the node We will make sure to clear it And that actually turns out to be a really good solution if one of your core assumptions is we cannot put data on nodes But it's actually a lot of code right and this is I think this I think Uh, it reinforces sort of what I what I'm saying, which is it's easy to imagine Oh, it's an ie hack. It's probably like three lines of code sometimes Sometimes the assumptions that you make in your code either Old ie ruby 18 or whatever the assumptions are in your personal code in your application Sometimes the assumptions really drive the entire architecture of your application your application the first project I worked on involved microsoft project and a lot of the assumptions that we made had to do with things that microsoft project Did in the first version but years later nobody used that version anymore And really it behooved us to go back and think about whether the architecture or our entire application even made sense anymore so The interesting thing is as long as we support old ie We're going to need this code as long as we supported that old version of microsoft project We're going to need that code and this is this sort of explains that gap That gap in technical obsolescence right as long the the gap grows slowly the gap creeps up on you because for a long time The assumptions that you made they may be becoming less and less relevant, but they're not irrelevant So as long as you require old ie You're going to need this code which means you're going to build up an immune system because people You know zepto is going to come out and zepto is going to say hey jQuery you suck Why do you have this crazy code? You should remove this code and jQuery people are going to say ah little do you know but if you do that You're going to have a memory leak in ie. I don't care Right But what happens when old ie becomes less relevant? And the answer I think is what jQuery did Uh about a year ago jQuery did a full analysis of basically the entire code base to try to figure out We didn't do a good job of tracking our assumptions over time But we did an analysis of the entire code base to figure out what assumptions were in the code base based on earlier browsers And by keeping track of the reasons in the months and a year ahead and analyzing that We were able to determine what the cost of removing old ie was right So I think there was we've been receiving a lot of complaints over the years Hey, you should just remove all ie and there'll be thousands of lines of code you could remove And for a long time we just had this general feeling the project had received wisdom that There just wasn't that much of a win and in fact it turns out in retrospect that that received wisdom was true But only until ie eight after ie eight. There's a lot of code So what's the life cycle? What's the life cycle of a project the life cycle of a project is in the beginning the cruft Is a real solution the cruft matches one to one with the assumption that goes into it Over time you develop cruft defensiveness you say I don't know. I don't know why we put that there But it was probably there for a reason or or hopefully better yet. That's there for ie. That's ie fix But over time a gap appears and unfortunately The gap usually grows before it really becomes pressing and important that you deal with it So you get you you get back into a crouching position. You you Man the fourth you say I am sure that this is a real thing.  You're not doing all this stuff and it wasn't just ie right it's a whole bunch of stuff and So over time The received wisdom gets consolidated and more and more no matter how big the gap gets you always as a project have an excuse For why this is happening But eventually what happens is some new person comes into the project your application Some new person releases an open source competitor where it turns out that the gap got so wide that there was a lot of wind That could be gained simply by readjusting the assumptions starting the assumptions from scratch And because of the fact that the normal mode of operation is consolidate retrench You usually miss it. You miss the opportunity to fix the problem So what's a better way to deal with this? What's a better life cycle? I think people should track their cruft Maybe in cruft.txt Maybe cruft.markdown I think people should when they build when they write some code. That's not optimal when they write a mess They should write down somewhere not in line in the code but somewhere what the assumption that went into that code is and to allow future people to say This assumption does not is not valid anymore. We are going to remove that code And I think this is especially important the more parts of your code base it touches Again, I don't think it's ever possible to fully isolate these assumptions. You have to build code You have to ship software the assumptions are real But it actually is very important for you as a part of your project life cycle to periodically say that assumption that we made Is that true anymore? Ember is already starting to do this. We're only a couple years in and we're already starting to say Did things that came out over the past few years affect our original assumptions? Does the fact that older versions of ie that es5 is becoming a more valid thing for us to care about? Does this affect our decisions and in fact it has In fact, even in just a couple of years There's things that we can do to radically improve our architecture just by taking advantage of the fact that One of our assumptions, which is we have to support old ie is slowly fading Maybe we can't fully solve it. Maybe we can't drop ie support, but we can really start thinking about how to how to move for Now on the flip side of that it is okay For a for you to be the dom library for ie6 users if you had a construction management app that supported some old version of Microsoft project it is okay if you as a project decide We're going to be the construction management app for Microsoft project 98 That's totally fine. That might be an assumption that is still valid for your project And I think that is that is a valid conclusion that you can make when you're reevaluating your assumptions And this whole discussion is not even just about the support matrix I sort of I've covered this but there's a lot of assumptions. There's a lot of inputs that go into the decisions that you make and I think So a good a good example of this would be rails right so rails I think Is based around the assumption of rendering server side html in large part I think there's a lot of really good things that rails does for json apis I use it for json apis But I think there's definitely a world in which the gap continues to grow right now the gap is rather small But I think there's a world in which the gap continues to grow And so there's assumptions that enter into things like rails and jQuery But also your own applications that really don't have to do I don't want you to take away from here Oh, I should think about whether I still have to support ie6 That's definitely one large set of assumptions that goes into how we write our code But there's a whole other set that are basically based on the human beings that use our products So what do I want you to do? I want you to keep track of the edge cases in your code I want you to keep track of the assumptions that enter your code I want you to keep track of What the reasons that might might cause technical obsolescence And I want you to think about how those impact your architecture So don't just don't just say I need to support ie6. That is an assumption I want you to really think about What how much of your architecture is based upon these particular assumptions I want you to periodically review the decisions that you're making As a result of these assumptions and I want you to make your choices More intentional when you think about Whether or not you're going to do something or not I want you to really think about what assumptions are going into that and I want you to document that I want you to help contributors To your project or to an open source project make decisions without fear that they're walking on a grave Thank you very much Josh, do I have time for questions? My clock says 30 something minutes We do have time for questions and I'm going to start Okay How about the test suite as a place to track cruft? Uh Someone else asked me the question the last time I gave this spiel So I think the test test suite is a good place to track cruft and I think for every piece of cruft that you have There should be a test However, I think the the point that I'm trying to make is there should be a place where that's the only thing that that's Things job is right. So there should be a file where the job is Here is a list of assumptions and how they affect architecture and not I am a new user I'm going to run the test and see if they fail right. I think that's important It's important that if there is ie6 needs to be supported that you have tests that check for these ie6 bugs very important So I can think of more than one occasion where I've been writing code to work around a bug or something like that That I knew would eventually get fixed and I wrote a test to Make sure the bug was still happening. Yeah, I think that's when it didn't happen It would fail and tell me take this code out. Yeah, so I think actually that's a really good strategy for things like ie6 bugs Less of a good strategy for my users happen to use some version of microsoft project that has this bug We don't necessarily always test all those things. Maybe if we could test all of them, it would be great But yeah, I think there's you could sort of break what I said into two chunks There's assumptions that are essentially code assumptions there ie6 does this weird thing or Ruby 1 8 does this weird thing and then you can I think you could really nail those with tests And then there's a whole other set of assumptions which are just human assumptions things that my people my Like in my first project the fact that everybody's all the contractors still use fax machines Right. I can't really write a test about that, but it is a core assumption. We had a lot of fax code Okay, good good points. So other people questions I always got to work out at these things so there There are some Parts of your talk particularly early on that sound a lot like overfitting training data in machine learning Is that a thing you've thought about is related to this? Do you? Do you deny the connection or accept it or? Uh, can you say more sure so in machine learning you have I know what overfitting means okay draw the yeah, okay, so In machine learning the overfitting is you take some training data and your solution is too perfect to that training data so then when you try it on a Extension set a real set of data. It is no longer valid And when you put your graph up at the beginning of when you draw when you write the code event at first The cruft is exactly a one-to-one fit to the current model of the universe, but that model changes over time so maybe In machine learning what you want to do is take like a slightly worse hit on on training right write a less than perfect solution Is that something that could help us write code like accept a slightly imperfect solution as a longer term more stable solution? Yeah, I think especially so interesting connection I think especially in so far as We're talking about things where the trajectory is predictable People will use less ie six over time right Turns out to be true People will use less of some current browser over time You can perhaps be less perfect although in a lot of those cases you are forced to solve the bug for ie But perhaps you can isolate it better. You can project. I think I think that's a good solution I think the tricky bit though is that it's not that it's too perfect For some set of data. It's perfect for now, right? So you actually do want to write code that's Perfect for now if there's a trade-off between Perfect for now and good enough for later definitely take the good enough for later trade-off Sometimes it's just like does it work at all right now? And I think to the extent that that's an important question I think we should solve the problems that we have today, but we should make sure we understand What that's going to mean tomorrow if this assumption is no longer true. How does that affect the code that I just wrote? There's somebody all the way up there Uh, so like you said, uh, some of the things assumptions get too outdated And since we are all operating in the open source world and not as big as apple Uh, and like apple said, we are not going to allow any flash play on iphone So when do you make that kind of a jump by saying that now ie6 is no longer a feasible option? Or the gap is too huge that it's going to take more Work to support ie6. And when do you make that? Sort of a judgment call and remove the old assumptions that are no longer valid And the second part of the question is how do you measure? And bring come out with this data of how big the gap is so that somebody can make the decision of removing that support So I didn't really understand the first part of your question. Um, I can answer the second one So I think thinking about measuring the gap is not Right, I think the the point that I'm trying to make is there are some assumptions and you could intuit You can understand that there is a gap that grows between the assumptions that you made when you wrote the code in the first place And the reality sometimes things don't change a lot, but in the fields that we're in things usually do change a lot So in fact depending on how On how close the solution you wrote was to specific assumptions There's going to be a different amount of gap. So I think it's it's more of a human question, right? So human you haven't usually usually the answer is a new guy came into your project And he's asking some uncomfortable questions, right?  That's a pretty good time to say Okay, we did it like that because we supported some old there was a bug in some old version of flash that we needed support Is that still valid? There's a there's a some code in rails that I think might still be there It's like safari 2 didn't strip out Spaces at the end or something and like adds a null byte, right? So it's not those cases aren't urgent But presumably every time when someone new comes in and goes through that code They may notice it and it's good to know what the answer is, right? So the point I'm making is if you don't know the answer to why you're doing something the answer is going to be Please don't touch that um Hopefully the lesson takeaway from here is try not to have the answer ever be. Please don't touch that Try to have the answer be Here's the reason why it is and the assumption is still valid or it's not valid anymore Are you are you leaning by example in this case and uh doing this on ember Or some other project where we can look at how it works out in reality? Yeah, good question. So, um I don't have a cruft.txt, but we do have um architecture files that talk about the architecture and the reason for them After writing this talk if I have some more concrete specific things to do and I definitely think that this is a good idea And people should do it I um the The lesson came from jQuery where I saw the amount of work that it took to reverse engineer what should have been cruft.txt and um I think that's always possible and that's what you should do five years in if you're stuck But I yeah, I mean definitely gonna I'm definitely going to be a lot clear in the architecture Files about what the reasons are for doing specific things going forward Uh, that's it for now. Thank you very much. Thank you


The study proposes a new approach to estimate the neural drive using a deep convolutional neural network, CNN. It uses data from different contraction tasks, different intensities, learns general features of MUAP variants, and estimates the neural drive for other contraction tasks. This allows for a more efficient and accurate neural drive based human machine interface that is generalizable to different contraction tasks without retraining. This article was authored by Yuan, Sanjun J. Kim, Simon Avrilon, and others.


I'm very happy to be here with Alex Osservard and then Pink and it's really an opportunity for us to talk about one of the key research we are doing now on transformation and talking about motivation and how to move people. So you early today Alex said about this concept of exploration and exploitation and in most of the incumbent organizations they are on this exploitation environment and it's so hard for them to shift the way they behave and the people think. So I would love to hear from you what would be your advice to C-Level executives to drive this kind of environment in the inside organizations. So I'll start with something very simple it might almost sound condescending but I think senior leaders and boards maybe even investors should start to understand what innovation really is because when I hear CEO say everybody needs to be an innovator I immediately know they don't really know what they are talking about because innovation as one word doesn't make sense. There is efficiency innovation which in exploitation you make better processes and that sometimes can look very sophisticated AI and so to make your existing business better that's good. But then on the other end we have growth innovation transformational innovation which is very different. So these are both used the word innovation but they are very different. Efficiency innovation is easier to do is more about management. Where it gets hard is transformational innovation. And now back to your question what can you do as a leader well understand and then commit at least 40% of your time in your agenda every week on innovation because if you just say it's important but you don't do it what's the symbolic message you are sending to the company right? So innovation needs more power and that's actually relatively easy to give right but it does mean you need to educate the board you need to educate investors that you're in it for the long term that in the short term you can't do transformation. So building this kind of dual culture yes I'm spending some time on my you know existing and managing that but at the same time really investing time energy money and mindset into growth and transformation that's a symbolic value to the company. And those who are at the very top of innovation Amazon Ping An they're doing that their leaders are investing their time and energy in innovation and that's a very symbolic value like Jebesis likes to say we need to keep a culture of day one when that doesn't come from the top guess what not going to happen it's as simple as that right then that comes back to motivation and we put in place the right incentive systems for those things to to actually take off. What are you you have an amazing research on motivation what would would be your advice for these leaders? Well I think it's not only motivation I think as Alex is saying it's structural too so what what's the structure and I think at a very top level if you if we go with Alex's idea of explore and exploit I think that the the one of the fears with putting an emphasis on the explore side is that they feel like it's always coming at the expense of exploit and I think what we need to do is say like we can do both of these things it often involves different structures it often involves different people and I think it also also involves different motivational schemes but to put time and effort and energy into exploration doesn't mean that we are going to deny the importance of exploitation so I think that's at a top level at the at the other level again I think there are two things structural and motivational what we know what what I think structurally is I agree with Alex mostly on on two big points one I not only doesn't have to come from the top it has to be honored it doesn't even have to come from the top it has to be honored at the top and has to be honored in the day to day behavior of the people at the top so if the people at the top are saying one thing and doing something else all that does is harden the cynicism and and and we all know that it seems self-evident yeah but the number of times that that happens yeah is so much greater than the number of times that it's actually actually the words and the deeds cohere the second thing is that I have become over time a bigger believer in starting small and and I think that instead of saying how do we become more innovative I think the question is reframe the question so what's one thing we can do tomorrow to be better at exploration and I think if you start thinking about it that way it becomes more do a little people so I don't know if it's 40% of the time maybe it's even a much much smaller percentage of of the time maybe it's one day or maybe it's one day a week so 20% of the time or maybe it's maybe it's one afternoon 10% of the time but actually something that is small and doable because what I have found is that in some level the way we think about organizations and I think it's true for project managers get it get a sense of this too is that we've kind of we've we've overvalued big hairy audacious goals and undervalued small winds and so small winds are actually really really important now when it comes to the motivational side once we have the structure what motivates explorers is different from what motivates exploiters and what motivates explorers is having a sense of autonomy some sovereignty over what you do how you do it who you do it with the chance to work on something insanely cool to make an impact and to work with great people and that's what that's what it is and it isn't about saying whoever has the best idea gets a bonus in fact I can that can actually there's a lot of there's a lot of research showing that that can actually inhibit performance I want just to build on yeah on what you just said and we did last year one one research and we came with some statements and we saw that one of the biggest roadblocks for organizations incumbent organizations to move and change it's on the people side and I'm saying people on their own interest yeah it's something like for example it's not a matter of putting money to transform the business but people need to feel how they fit on the future because if they see that the future is is really very scary for what they do today how to change this this behavior yeah if you are a large company I want to connect it back to what what Dan just said and what's important is people within the structure so I think you really hit the nail on the head because some people are better at managing right and exploitation and some people are better at exploration with uncertainty right but for those you know strengths to really emerge you need to put in place the structure so both can give their best right and what I think we don't have today is the space and that's not just a physical space we often have that but the mental space the metric space for innovators to really blossom right so many people will try once and it doesn't work they'll go to the competition they'll try it twice and then they become entrepreneurs so what established companies need to put in place is a structure where innovators and ideas can really bloom and then back to what you said about you know small matters I think that's actually one of the big challenges so what gives you prestige in an established company is a number of people you're managing yeah and the size of your budget now here's what happens in innovation actually a lot of in venture venture capitalists like Vinod Costa they say if I give a team too much money they're actually gonna blow it so the more money you give a team the likelier you are to decrease the success now why is that because in execution we need to build a new factor we need 500 million we need a billion there it works big numbers so we think oh we need to make a big splash new growth business we're gonna give them a lot of money what happens when you give a team a lot of money they actually build the thing Qualcomm is a good example they built something called flow TV beautiful idea on paper great business plan so they invested a lot they built it nobody came they had to fire the few customers so in innovation in growth innovation in particular better off sparting small with many many projects to help those ideas that can get traction those teams that contract get traction bubble up so you need to create an ecosystem where you invest in many teams yeah and small investments and then follow-up investments so the system will help you get the best out of people so people matter but people won't be able to matter as much if you don't put in place the structures that you were talking about me well but P I mean because people like everything we do in life is in context so it's not as if we behave in a vacuum we behave in particular context and the context drives our behavior more than we're willing to admit on almost every dimension of human behavior one of the you know it's what it's one of the core principle it's one of the the chief cognitive biases that human beings have particularly human beings in the west have is what's called the fundamental attribution error when we try to explain people's behavior predict people's behavior we over emphasize the importance of the personality who they are and under under weight the importance of the context that they're in and so you can have people who are extremely innovative in one context who will wither in another context so we have to think about people in contact the person in the in the situation and both are and I think both are really important and what we know about this is I think we know I think we know actually a decent amount about all I think we know how to do this more or less and Alex make some great points some the importance of some amount of constraints there's a sweet spot between two something that's too constraining doesn't foster innovation something that has no constraints lots of money lots of people doesn't have enough constraints so you want some and their ways to their ways to experiment with that I mean not to deify Jeff Bezos but Jeff Bezos has this idea of you know the two pizza theory of innovation where the number of people you want on a team is a number of people who could share two pizzas you have more people than that that's not you know and so I think literally heuristics little things like that are really important so put the right put the right people in the right context and try stuff and keep doing what's working and stop doing what's not working and you have to just you know you have to as Alex is saying you have to just let a lot of you have to let a lot of things a lot of things bloom and you also have to do it in a hard-headed way this is not kind of a hippie-dippy idea this is the idea that whoa wait a second if something does bloom wow wait a second this flower is actually blooming let's go gather the seeds and give it to the exploiters so that we have a forest of it rather than just a single bloom and let me build on that for a second because I think we always when we say innovation we think of creative genius you know the person who's going to be on the cover of a magazine you know actually when you do design you come up with new you know industrial designs or architecture you go through a training to go through a process of continuous destruction and reconfiguration till you figure it out so there's this myth that innovation is about creative genius or creativity there's part of that you know ideas are free and cheap there is a process that we now know how it works and we need to incentivize people in innovation to behave the right way it's not about giving them money and say hey have some fun experiment and figure it out there's a process of how you decrease risk and uncertainty of ideas the more you decrease risk the more you invest the more traction you get if you invest in 20 to 40 teams every year you will know that if they follow the process you will get some winners it's simple portfolio theory right now if you're too restrictive you actually kill the creative genius right so you need both but you need to figure out the right processes incentive systems so we can distinguish between vision and hallucination right so you get the right ideas to bubble up


You're taking up, like, all of the space. Why do they want to see you exactly? They don't... Ah! Ah! We look like the fifth graders. Hi, bitches! My name is Fetty Wop today. I guess I'm Lettuce Wrapp. Lucy has done my makeup a couple times. Here are some pictures of it. Lucy's a very good makeup artist. Here's some more pictures of it. So how about I try to follow one of her makeup routines? Because usually she has to babysit and help me throughout every single step, because I'm not that talented with it. You're getting there. I am. So I don't know what makeup she's doing. I told her do whatever you want, make it as hard as possible. Like, I would like to try to fail. Scoodle so I can tell them what look we're doing. Go away. Go away. This is my channel. OK. So you're the one who didn't want to know what the look was. All right. So on Instagram, I have this whole, like, inspiration box. And so on Friday, he was like, hey, I want to follow one of your makeup routines. I was like, I don't really have a set makeup routine. And he was like, just do one of those looks that you always do. If he can do that, I will go. The look I have is by this one named KC Garces or whatever. Let me try to show you. That. Good luck, Freddie. Loser, come back in. So did you explain to them? Yes. OK. So we're going to zoom in a little bit.  So you can see our pores. You're so short. No, you. You're an inch taller than me. All right, what's the first step? Sensei. I prime my eye first. Prime your eye first. I have concealer. I would introduce you to each one of my pores, but I would take too long. The hair was good, but it's also. Facts, facts. Much in the way. Oh. You're doing amazing, sweetie. Keep it up. Thank you.  I'm up to where to start going with eyeshadow. Well, I should. Yellow is an annoying color to work with. So I have to use a denser brush. So I kind of just like pack it on. Oh, I can't tell. Oh, you don't mind as well. We're doing a double cut crease today. I knew it. I knew it. She always does those.  Build it up. What are you doing? Build it up. Yeah, OK. Next. Senpai.  We're going to go into orange next. Tap it off. Tap it off. I went in with a light touch, so. But you want to start a little and build it up. OK, where? Above your crease, but under the yellow. I'll watch you. OK. Is this orange going to the inner corner too? What did you do? Did not tap off is what I did. I can fix it. I am actually not a makeup artist.  I thought the earrings have it. No. I thought we were going more dramatic. Wait. No, we are.  I don't have much space. Exactly. You got to work with what you got. We're going to be at the end, and then mine's going to turn out like garbage, and yours is going to look fine. I don't know about that, but OK.  What? That's what you're supposed to do. When you lose yellow, you go back at all. I'm not dumb. He's overtaking me. I have watched my affair amount of makeup tutorials. You watched Jackie Aina. You watched Jackie Aina with her huge eyelid space. That's just some serious real estate there. This is what I don't get. Does your eyeshadow wing out? It's just like a circle. I just do a normal smokey eye and then cut it anyway, because this is winging it out. Yeah, and like working with like a fluffier brush. It never puts anything on like too heavily. What do you mean? He's going for an offline guard look. Oh, so if you thought I would zoom in enough so you can actually see what we're doing, that's false, because this is not supposed to be a tutorial for you guys. I mean, why does my hair look more vibrant than mine? OK, we're going to go in with that orange now. Another orange? Yeah. Why? Because it's a deeper orange. I can't even hold my mirror straight right now. You're doing better than I am right now. I don't think so. You are. You actually are. The thing is my eyelid is so small unless I do this and then lean back. That's what you're supposed to do. OK, we're going to move on to that one next. Why? Oh, I did that one. I already did that one. You moved on without me? I just wanted to make it super nice soon. I didn't think that orange is anything. I feel like this was a following. I feel like this is a following. While she's blending, let me give you a close-up of what I got so far. So like, while I'm not trying to say that I was Freddie's makeup awakening, I'm also trying to say that I was Freddie's makeup awakening. This is what we got. That's, oh my god. I just feel like so much fall out there. Yeah, that's what we got. They're not even. I'm not fixing it. Lucy, show them what you've got. No, I refuse to show them right up until the end. OK, fine. What's the next step? We're going to deepen. More?  What do you take? Black? It looks like I have a sickness underneath. No, it looks fine so far. Well, let's cut the crease then. No, because it'll look bad. You have to keep building it up. I've built it up enough. Build it up more. The yellow's gone. You're doing surprisingly well. Thank you. I appreciate it. I'm debating if I should ever stop you if you make a mistake or if I should let you keep going for the comedic effect. I have to do this myself. Comedic effect. Sorry, can't help you. I have to let you figure it out by yourself. Most likely it's your too much gene acting. Yeah, it usually is. When you're going in with the black, do a very small amount. I know now. It looks terrible. See, this is why we fall low instead of going I knew you would use the black. I just did two taps. I've been winging on my eyes. Got in my eye. This has no yellow in it. He specifically asked for it too. He was like, let's do a difficult one. No, I know, I know. I'm not touching it. That's a good idea. Maybe I should deepen the black. For the sake of my sanity, I'm not going to do that step. Can we cut the crease so I can have some? All right, all right, all right.  This is where I mess up now. I feel it coming. Where it is, he said. This is a trait that like a lot of people do. Like, look, come on, come on. Like, when you're back. Sure. Yeah, I went up a lot. Just make sure that the black isn't completely gone. Like you want a sliver of black. It's gone. I went too high on the right. Gee, really? Yeah. You think? I love the cut crease stuff because it just fixes everything. No, it didn't.  Because if so, please take my line of brush. Once it's dried, because if it's not dried and it carries throughout the entire thing. What if I just redo the whole eye? Sure, if you want to do that, you can probably do it in the same amount of time it takes for me to cut my crease. I'm going to get a cotton pad.  I'm going to die because all the work I have to do again. Anyway, if you guys are looking for unproblematic Asian beauty gurus, there's always me. I've cut creases. I don't know how I caught up so fast. I just mixed everything together and pretty well. You caught up so fast because I sat here for 30 minutes. Focusing. Why is Chubby here staring at me? Focusing. Where are we going after this? Can we get dinner? Sure. Yay! My name is for safety.  I'm kind of really annoyed too because it's good. I did it. Yeah. We're essentially going to... Redo it? No, go up. Here we're going to create like a little liner thing right there and it's going to be a whole bunch of colors. And then we're going to cut it because we're going to do it with powder so you can be as messy as you want with... No, it's good though because you can be as messy as you want with the powder and then just fix it with the concealer. And we're going to go on with this red shade first. The sparkly red shade. We're going to put it in the front part. I gave him... You know what is prom? He did his little get ready with me. The palette he was using was in there and I cried just watching him like, here, I will show you. I don't think you can see. There's an indent in there from just jabbing it in. Oh, we're going to go in with the bright yellow. The next sixth of your eyelid. And then when you're done, that blend them with that orange shade. So just stick it in the middle. Oh, this is a rainbow look. Yeah, I told you. I forgot what I didn't tell you. But I was like, you know, it's Freddie. Like I have to incorporate.  We can just do an orange look. No one's incorporating pride after Pride Month. Oh, that doesn't go, you follow my Twitter. Should I not be following your Twitter? No, but you should be. I did a gradient. That's what you're supposed to do. We have to get them close up some of the stuff. Because this is a relative success. I'll be the model. This is what we're at so far. It looks great on camera. I will say that much. So what do you do with the purple? You wing it. Just like the very end. Do you wing it though? Your cut crease is already a wink. I don't get it. I don't know how far to go. Just go until the end of your cut crease. Oh, it's very long. That's what she said. What's the next step, ma'am?  No kidding. More concealer. More cutting. Where? I don't have the space. She's such a joke. Girl. Yes, you do. Are you kidding me? You're lying. One second. I will literally mark this for you. Oh, don't blink. Well, I blink when you jab me.  I put a lot into this.  Thank you. I still like my left side more. Oh, that's perfect. I like my right side more. So we'll just... Next step. I don't know if I'm going to use eyeliner or black eyeshadow. I think I'm going to use eyeliner. So all over my lid? No, no, no. Just stay at the end for now.  I'm taking the con pet. What's the next step? Eyeshadow. We're filling out the lid. Oh, lower lash line. I forgot. No. This was an exceptionally hard look for a beginner, my bad. And then what's the next color? Lighter blue, then darker blue, then darker, darker, darker. Blue until you blend it into the black. Oh. Wait, where does the dark blue go to? Just like blend it in. OK. You're going to see they just like mesh it in with the black. This side walked so this one could run. I'm done. I'm proud of you, sweetheart. What's in the lower lash line? Just whatever is up here. Don't be here for a little bit. Oh, it's on my chin. OK. My foundation is basically done. The next part would be concealer. Yeah. I also don't put a lot of concealer on either. My concealer is too dark for me, so. Forehead nose, chin, and lip. Oh, oh, my God, I don't think. Oh, it's the following my makeup. Forehead nose. Oh, why is this concealer drying so fast? All right, the next step is powder. My mom was like, we see you have an addiction to makeup. And I was like, I could also have an addiction to alcohol and drugs. I think makeup's one of the better ends. What did she say after that? She was like, it's still an addiction. And then I'm going to lightly set the rest of my face. I mainly set my under eyes and my forehead, because that's where my forehead creases very easily. Now I just do everything out of order. I think I'm going to do bronzer next. This is going to be the first time he does bronzer by itself. I usually do it for him. Wait, do you have to do the lower line or anyways? Yeah, but you're not doing it yet. Be patient. I'm almost done. Is this also contouring? I don't really contour, but yeah. When I'm not doing dramatic makeup and I don't need my highlighter to like, I do blush after my highlighter because it just blends in more. And that way it doesn't look like a strip on your face. But you know, and when you're taking pictures of makeup, you really can't tell that it's a strip on your face. It's kind of nice to your face. Okay, fine. I've been adoring blush recently. Oh, I put too much on, but you won't.   It's too pigmented. Okay, what's next? Highlight. They're like right in between my eyes, like right there. And then on my bridge. I want you to go through my five-step lip routine. But we're first going to do eyebrows. Or I'm going to do eyebrows because I don't have any and you could just sit there. Oops. What'd you do? Oh, it's not the right direction. What now? This? Lower lash line. Wait, so I have to make yellow, orange, and red pop like show up on the lower lash line. I would start with like the deepest color when it comes to your lower lash line, whatever, you don't even notice the lower lash line when I do my makeup. Oh. Okay, well, I'm going to go do inner corner because that's self-explanatory. Here's step one of my five-step lip routine. The main thing is I get rid of the bridge in between because I don't like how it looks. So I draw over it. I like my bridge. And it makes your lips look bigger and everything. Just over line.  I already have full lips. Sorry. Why not over line? You ready? So we're going in with. This is a staunch. It's a deeper lipstick. All my lipsticks look the same because I geared towards the same color. And it's this.  This is like my lip color. Isn't that wonderful? Okay, you're done. Now put this in the middle. That's a lighter lipstick and you're just going to stick it into the middle. I'm going to use my favorite step. You put gloss on.  Because it's all my lip shape and not for yours. We're going to use Lily Lashes Miami. You want to wear lashes? Brush on adhesive. Ew, okay. Everything from the lip up looks great. And then you look below and it's like. There's no reason I'm able to get away with putting on lashes in the worst way possible and still look normal. Anyway, children, we are done. All right, let's get them a close up. You can go first. My foot's asleep right now. I can't get up yet. Fine. This is the final look. Oh, my lips don't look bad. No, they do. Never mind. Like if you do this, my eyes look great. I will show you the details of the blendage and don't, I mean, it wasn't that good underneath, but. That's what you were, that's what we were doing.  Yeah, so. Yeah, you did it. I didn't. You don't forget. Ignore the lashes.  Well, if you enjoyed this video, give it a like, leave a comment down below or subscribe because both videos every Saturday and some other days sometimes. Socialists are here. You can do the thing. All right, children, do not forget. You gotta hit that notification bell. If you hit that notification bell, you're guaranteed. You know, summer's like ending.  As always, the name will be anonymous, but you guys know that I say these coming out stories because I want you to be authentic to yourselves. So you can go ahead. I just came from the painting, my graduation cap video. And firstly, it looks amazing. Thank you. Yes, it does. Our boy here is super talented. Secondly, I love that you read coming out stories at the end of every video. So I thought I'd just go ahead and tell you mine. The first person I came out to as pansexual was my aunt and my mom because we were really close. And I started seeing this guy who was transgender and most of my family is really supportive. So I'm lucky. Other than that. Yes.  I'm 14.  You know that ad? I'm putting the ad in there. All right, well, thank you for telling us this. You are incredibly brave for being able to come out like that.    Thank you for sharing. And as always, I love you guys and everything. Oh my God. I love you guys and everything is less than three. All right, can we take the photo now? It's six o'clock. The sun's at, you know, sunset hour. We don't want to go eat food.  Let's go, let's go, let's go. No, get out. Bye guys. Out.


The Akitis State Transition Committee of People's Democratic Party, PDP, has recommended the suspension of former Governor Ayo Faiyoshé from the party in the state to their national body. Addressing journalist, the state public's desectricated transition committee of PDP, Donald Amiri Joye, said the national body of PDP should approve the recommendation by the stakeholders in the state to expel Faiyoshé in order for the state chapter to come back to life again. The session 58 of our party coalitions stipulates the offensives and what qualify you as members of the party. If you claim to be a member of this party, are you afoul of the rules of the party, working against the party, and don't see the equivalent governor again the wish of the party, such individual, I pray, cannot be regarded as a member of this party. Whoever is faulty, the rules and regulations of the party should be suspended, that's been done. And you know, when they stick out of the party, they saw the decision, the relation will go to the IR authority. So we are expecting the response of the IR authority. News updates.


So it's like, as we've industrialized, many people have had issues with working inside of factories and having exposure to certain classes of chemicals, but then also there's just on a mass population scale, those that have progressed to, let's say, just advancing countries into whatever first world countries that they're exposed to BPA and other forms of exposure to endocrine system implication that then cost things like infertility. This is all very interesting because there's so many downstream effects that it's hard to measure longitudinally over like 50 years, what it does. I mean, we were just talking about this earlier this episode, just people being jammed into little boxes on top of each other in metropolises, well, when you don't get that much natural light, when you're not getting that much exposure to fresh air, when you're not getting that much exercise, you're not getting enough sleep because there's just economic machinery pressuring you all the time, you're far away from your family, you're far away from raising children, all this type of stuff. There's many downstream implications that happen, including the onset of cancer and cardiovascular disease and Alzheimer's and all these other things that are very difficult to measure this, the intricacy of the nuanced multivariability, yet it's quite physiologically evident on a moment-to-moment basis when you actually feel like you're divinely at your peak state of performance versus feels like me inhaling the cars exhaust on the street in a breath of air feels like it actually sheds minutes off of downstream my life versus indigeneity, people that are still living in complete symbiosis with nature. They have just a much more cohesive understanding of the interconnectedness of everything plus their environmental anthropological awareness level must be like a 90 on a scale of 0 to 100 and ours in metropolis feels like it's 20 or 30. It's disastrous, it feels disastrous.


Welcome to this CUBE conversation. I'm Lisa Martin and I'm joined by two CUBE alumni. Please welcome Ehab Terasi, Senior Vice President and CTO Networking at Dell Technologies. Ehab, welcome back and welcome to the virtual CUBE. Yeah, thank you. I'm excited about this. Thank you. We're going to have a good conversation because Vijay Ramachandran is also here, VP of Product Management at VMware. Vijay, welcome back. Thank you, Lisa and happy to be here again. So with a lot to unpack, we're on the cusp of VMworld 2021. You guys are making an announcement. We want to talk about NVMe, why it's important or break down the announcement. Go ahead and start, Ehab, we'll start with you. NVMe, why is it important? What is it? All that good stuff. Yeah, this is excellent topic. And this is really an important component of infrastructure these days. Modern applications are changing how they consume infrastructure. That's because the workloads are evolving. Some of them are AI type machine learning workload that need very high performance. There's also a continued trend by our customers to put workloads in public cloud and on-prem and create a hybrid multicloud model. And also the new exciting stuff is all have to do with edge applications and distributing applications everywhere with automation and connectivity to where they need to be operating at on-premise. So long story short, these trends, these new applications, how the deployment models work is really diving the need for NVMe becoming the key technology for getting your data and storage. And with it, NVMe over fabric and connectivity is starting to become a very important topic. How do you have this discussions with customers in terms of their next steps, especially in the last year and a half, Ehab will stay with you, that we've seen such acceleration of digital transformation. What have those customer conversations, how have they changed? The conversations have changed in two big ways. One, they really want to discuss outcomes. They know that we can bring industry leading infrastructure and tools and automation and software, but they really want to discuss outcomes. How do I automate my operations? How do I get to unpack the value of my data no matter where the data is eyes and where it's coming? So that's the first big change is people have shifted completely to outcomes. And the second change is that now there's a really good discussion about performance and sustainability. How do I make sure that I'm meeting my sustainability goals? I'm meeting my performance goals instead of just discussing one piece of the solution. Got it, BJ, I want to bring you into the conversation now. Talk to me about NVMe and its evolution from VMware's perspective and some of the changes that you've seen in the last dynamic 18 months in the market. Yeah, thanks for being here, Lisa. These are actually, I think that we are living in interesting times now. What we are seeing from the VMS standpoint is that applications are evolving rapidly and demanding more performance, lower latencies, higher throughput, and these are modern applications. And NVMe, what we're seeing is that NVMe as a protocol is becoming the de facto sort of connected protocol for these applications. At the same time, what we're also seeing is that the infrastructure team at scale, when they deploy these applications at scale, they are moving towards a disaggregated architecture in the data center. And all the enterprises are moving towards this because they want to emulate the public club. And so, what's exciting about this announcement and sort of what we're delivering together at Dell is that the combination of NVMe plus TCPIP provides, sort of brings both these worlds together. It provides performance and latencies that these new applications, these new modern applications need. At the same time, it provides a different way that is disaggregated. And so the combination of these two is indices changing in my opinion and we'll see that this will become sort of the de facto way to deploy infrastructure in our data centers. And that's what we're seeing at VMware. Got it, thank you. Let's go ahead and now unpack that announcement that Vijay alluded to. Dell and VMware have announced an end-to-end NVMe TCP ecosystem solution. Back over to you, Ehab. Talk to me about this. What is it? What are some of the core components? And then we'll get into benefits. Yeah, perfect. So we both see NVMe over TCPIP as this new future storage connectivity. And it is a pivotal moment for the industry. There's always been debate about what protocols you use for connecting storage, for performance speed, but the time has come for NVMe over TCPIP to become the de facto future protocol. What we're announcing is, first of all, we're announcing a new software product called SFSS from Dell. And that software product will automate the discovery, provisioning, and automate the setup of all the storage networking, how you connect all the hosts to the storage targets in a fully automated way. This is something that has been very complex, very hard to do manually, and a one by one. So that's a whole new software product. Number two, we're announcing the availability of NVMe over TCPIP on our key Dell products, which is PowerStore, PowerEdge, which is our server product, and also PowerSwitch, which is our networking product. So the combination of the new software tool, SFSS, and all the availability of NVMe over TCPIP on our compute storage and networking, that gives customers the end-to-end ecosystem to be able to use it, along with the VMware capabilities that are essential for it. Yeah, and Vijay, go ahead. Yeah, I was going to add to what you have just said. Of course, VMware is fully committed to bringing this, that option of NVMe, along with our partnership with Dell, to the market, and Dell has been, our partnership with Dell has been instrumental in bringing this to the market. Now, the cool thing about this particular announcement and what to bring to the market is that the smart fabric services manager is actually built into vCenter. So from a VMware standpoint, a vSphere administrator or VMware administrator can, so stay within their vCenter console and be able to manage provision, manage and monitor NVMe over fabric, NVMe over TCPIP connections. And so it sort of bridges the gap between storage and a VMware world that you will. And also the vSphere, the launch of NVMe over TCPIP and vSphere 7U3 is the last component of this announcement between putting SFSS inside vCenter, vSphere enhancements and the Dell products. The end result is the customers get this bump and new capability. However, they can continue to use all the management tools that they have today. So this is an easy automated lift and they get this new capability. An easy automated lift though, that sounds like magic to I'm sure a lot of folks ears. Ehab sticking with you, talk to me about, this is a new direction for Dell and VMware. Talk to me a little bit about that and the impact. I think the new direction is that we have supported multiple protocols for connectivity, fiber channel, RDMA. But I think now as we go to this next evolution and the fact that the world is going to multi-cloud and edge and distribution, the new direction here is we're putting a lot of investment and energy, both of us into making NVMe over TCPIP, automated and high performance. As Vijay said, we've been collaborating for over two years on this project jointly. That included new standards, new innovation, new software capabilities, new divers on all our products. So although we make it sound simple, this is a company-wide on both side innovation effort to make this possible. Absolutely a big innovation effort. Vijay, go ahead. Now I was going to say, just to second what Ehab said, we work as one team, we're doing two companies, but we work as one team and really brought some innovative features and functionality out to the market and really excited to see this come to fruition. We've been working on it for two years now. So two years before the pandemic started, I'm curious to get both of your perspectives on how the tumults of the economy and the market of the last 18 months have influenced. We've seen so much acceleration in digital. How has this interesting time affected or accelerated what you're announcing or has it? I will start and Vijay, whatever you'd like to add, is that I think what we've seen during the pandemic is acceleration of adopting of a cloud operating model by using more of public cloud, but also using automation that we have built into our products, both VMware and Dell. And so this kind of automated type software tools falls completely in line with that. Customers more and more want the infrastructure automated and they want it cloud-like with, as a service usage-based type models and we're both invested into that area. Yeah, and Lisa, if anything at all in the last two years since the pandemic, what we are finding is that it's no longer a decision between is it on-prem or public cloud, but it's actually an and decision. It's on-prem and public cloud. There's truly becoming a multi-cloud world. And so to make this multi-cloud and then customers deploy the right applications and the right workload in the right place depending on the needs. And so in this multi-cloud world, having this automation and having a consistent way to manage infrastructure in an automated fashion across these multi-cloud deployments is becoming key. And so this is a key component of that. What we're announcing is a key component of that kind of a model that customers are moving towards. Let's talk about the customer benefits. You both mentioned performance, sustainability, low latency, high throughput. Give me examples of each of those, of how this technology will deliver that for customers across industries. This is where we've really enjoyed working together and where Vijay and his team did fantastic work to test the value of having this partnership is the end-to-end customer sees the performance and benefit from the eyes of using both the software stack from Dell and VMware, as well as the infrastructure below it. And we've been able to jointly test what the customer will see. And what we have seen, which I have to say was a surprise to us. We expected benefits, but it even, it was one of those aha moment. Oh my God, this is, we thought it was good, but it turned out to be even better. So on the performance side, it's about two and a half to three times the performance of iSCSI, which is the other technology we would compare this to. And on the latency side, it's 70% less latency and uses even less capacity in terms of CPU. We have not seen that kind of performance improvement from a protocol for a very long time.  So I think the customers will be very excited about this. These are some submit numbers. Vijay, go ahead, extend on to that. No, I have nothing more to add because we have been extremely encouraged by the performance numbers that we saw. And here was right, we actually, it exceeded our expectations, right? And we knew that NVMe was the right way to sort of deliver performance. But to see this kind of results in real world is very encouraging. Mugres said there are several sessions at VMworld that are covering this topic. I'd like to get both of your perspectives on some of the sessions that you're presenting in and some of the key takeaways that the audience can learn. Ehab, we'll start with you. Yeah, I mean, we're starting with a session to explain the overall strategy and we're going to show demos exactly how would you use VMware software and Dell SFSS to configure, implement, how does that compare to the customer experience today? That's going to be an exciting session between myself and Paul Turner, who is the VP of product also at VMware. I think that kind of with these visual demos, people will see how fast automated that is, which is really the message here. Then we have multiple sessions from our key technical experts who are going to go through a deep technology review of the stack and how to do it and the functionality. Yeah, and Lisa, on the VMware side, obviously we have a number of sessions on various topics on storage. The one that I want to call out is there's a session that I'm doing with Mark Fleischer who's a CTO for storage and for cloud platform really. And we are discussing VMware's vision and strategy for storage and availability and NVMe is certainly a key part of that. But as we just talked earlier, the whole automation and the multi-cloud aspect of the parameters is critical. So we're sharing what, how we are approaching this whole multi-cloud world in this with storage and availability innovation. So I'm really excited about that. So a lot of news coming out on the NVMe over TCPIP front, talked about the collaboration, the acceleration of that, the directional shift. In terms of go to market and availability, when, where can existing customers go to learn more information? What's the joint GTM that Dell and VMware have? I think, Vijay, you want to start on vSphere and I'll add or? No, go for it, okay. Okay, so all the product we talked about today from vSphere 7.U3 power store, power edge, all of them will be available starting immediately after VMworld. And between October and November, everything we talked about will be available. And during VMworld, we will announce how customers can use it, download it, buy it. As we said before, because they are, SFSS is implemented into vCenter. This will be a familiar way for customers to use it, download it and implement it. And a new release of vSphere is something customers are used to. We have many customers on power store. So they will be getting a new software release and update with the new functionality. We do plan to create developer experience modules, sandboxes for people to play with will make more announcements on that in the future. Yeah, and this, as you have said, this functionality is built into vSphere and vCenter as well. And so the next release of vSphere will have this functionality. And you'll see a lot of noise about this at VMworld. That's sort of our coming out party. Excellent. Well, it sounds like it's gonna be a good coming out party with a lot of information to come around the VMworld time frame, some great education and deep technical dives that you guys and your teams will be providing to customers in all industries, which I'm sure they will be very much appreciative of. I appreciate both of you coming on, sharing with me the news. What's exciting about this, the impact it's going to make. And we look forward to hearing some of the news as it gets rolled out. Thank you, Lisa. Thank you so much, Lisa. Thank you. Great to have you guys. For eHob, Terazi and Vijay, Rahman Chandran, I'm Lisa Martin. You're watching a CUBE conversation.


Aymlango means internet at the door. Aymlango is a pioneer in the project bringing high-speed, saturated connectivity to schools across Kenya. We have the internet at our door, yes we do. Because of Aymlango, I feel that our people in this school have gotten a lot of exposure, technology-wise. Having computer labs in our schools helps us in educational programs such as math. Children's Encyclopedia Science English Composition in Mathematics And before we received these computers, we were teaching mathematics on using the books. And when we received these computers, people were able to interact. If you bring them to the computer lab today or maybe you take them to a cyber outside there, they are able to get access to information. Recently I learned about the history of Egypt, one being the mummification that was done over a million years ago. They help you search everything that you want. You can search about science, maths, every subject. The way it helps in mathematics is that it shows you calculations, some sums are calculated, but when you come to textbooks, they don't show you. In computer labs, they show reality how it is done. Aymlango has made our children to have a better future and I believe they are going far because they already know how to use the internet, they already know how to use the ICT, that is the program itself has really helped them. So I believe even later in life, they will be better than the other kids who have never seen that project. So it's a good project and it's a recommendable project. It has improved the pass rate of the students. When I came to this school, no students had A. In the history of this school and when I started using the computers, we had students who got A in mathematics. That means it improved very much. We are definitely not at the same place that we were when we didn't have this project. It has made us better as a school. It has made us better as a community. It has made us better as the teachers of this school and the peoples of this school and I can assure you we are going places if only you guys are willing to hold our hands together.


Hello and welcome to this presentation of the STM32 Global Interrupt Controller, or GIC. The global interrupt controller embedded inside the STM32MP1 microprocessor provides up to 288 interrupt channels with support of trust zone and virtualization. The application can benefit from dynamic prioritization of the interrupt levels, arm trust zone security extension, and for multi-core product, the interrupt distribution to each core. The global interrupt controller is tightly coupled with the ARM Cortex-A7 processor and provides a dynamic reprioritization of interrupt requests, allowing an application to better serve the incoming events. Most of the peripherals have a unique interrupt line, making the development of the application easier. No need to determine the source of an interrupt during the interrupt handling. In case of multi-core Cortex-A7 processor, each interrupt can be distributed to a single or both cores. GIC also fully supports ARM trust zone security and virtualization extensions. The GIC receives up to 256 interrupts from STM32MP15 peripherals shared between the two Cortex-A7 cores. In addition, up to 16 internal private peripheral interrupts, or PPI's, and up to 16 software-generated interrupts, or SGI's, are managed by each Cortex-A7 core. The GIC signals interrupt to each core with FIQ and IRQ. In a usual software implementation, FIQ is dedicated to secure interrupts. The GIC also provides virtual control and interface for each Cortex-A7 core, helping hypervisor and virtual machine implementation. Here is a list of the different type of interrupt sources managed by the global interrupt controller. Software-generated interrupt can be used to send an interrupt to the other core and private peripheral interrupts are mostly from timers. Note that there is one set of private interrupts for each core, which is completely independent from the other core. The shared peripheral interrupts are the usual STM32MP15 interrupts coming from peripherals, for example, UART. These interrupts are shared between the multiple Cortex-A7 cores and can generate interrupt to one or both cores. Note that an interrupt does not have programmable polarity and can be either rising edge or high level sensitive. Within FIQ or IRQ interrupt routine, interrupt's pending is identified inside the GIC by an ID number from 0 to 287. There is up to 32 interrupt priority levels. GIC includes a mechanism to avoid non-secure interrupt to get higher priority than secure interrupt. Using half of the priority range for non-secure interrupts allows the secure interrupts to use the full range of priority and choosing which secure interrupt could be protected from non-secure interruption. In that case, non-secure software can only see the lower 16 possible interrupt priority levels. Finally, the GIC distributor selects which priority is presented to each core. There is a separate CPU interface for each Cortex-A7 core, which presents either shared or banked register and either secure or non-secure register view. The global interrupt controller fully supports trust zone security and allows a flexible implementation of secure and non-secure interrupts. Virtualization is a system supporting more than one operating system at a time or multiple independent instances of the same operating system. The GIC helps support of such virtualization, for example, by providing virtual interrupts to a virtual machine. For detailed information, please refer mainly to the Arm Generic Interrupt Controller Detector Specification, ARM IHI 0048. Please also visit the MP1 Wiki pages for details.