C'est-à-dire les vues, et si vous voulez savoir la structure d'une table spécifique, vous pouvez utiliser slash d t, nice slash d, ok, on verra dans les slides. Slash d, backslash d, name of the table and then you get the list of fields in one of the tables, so that's the package table, so you see that we import basically everything that is in the package files. Is it big enough? Probably. So who is trying that? Can you bring it to your hand? It's a low success rate. So then let's try a simple query. What's Ryan email address? See Ryan something, no? Something like that. I think it's really... It doesn't make anything or it's okay. So that's the list of fields because I use select star and then you have the data for each row, which is not really easy to read like that, so we can just do select, for example source version, distribution component, and then you get, well, let's use release. So you get each package in each Debian release, so it's maintained. Yeah, so as you can see we also import data for Volatile, for example. So then another example, which is a bit more complex, so let's look at orphan packages, which is nice because it's not a two big tables, so I'm quite sure that we want DOS, you did using that. So that's the list of orphan packages. So let's just reduce it, so I will remove the description. So there are columns for the source package name, the type of orphanage, whether it's RFA, ATI, O, and the bug number. I know what we could try to do is join the orphan package table with Popcon to get the most popular orphan packages. So, well, that's the number, well, which is the number of orphan packages. So there's a table called Popcon SRC, which provides Popcon for source packages. So Popcon is usually for binary packages. So if you want to use it for source packages, you have to, it's the most logical way to do that, to take the maximum Popcon value over all the binary package of each source package. So that's the value that we have there. And there you have the name of the source package. And so we can just do a query like that. So joining orphan packages with Popcon SRC, using O dot source equals P dot source, and ordering by number of installation. So that's a rather simple SQL query to sort that, well, it won't work anyway. So here we can see that there's a number of installations and the name of the orphan package. So as you can see with a few steps of SQL, you can really get information that would be really difficult to get otherwise. So that's the Evensburg that is still not fixed and stable. So when you add the slide before the last one and you type next, it goes to the end of the presentation and you have to go back, which is kind of. So as you can see, UDD already works. There's not so many things remaining to do on it directly. But we really need help now from people who would like to play with UDD, use it to build new tools using UDD. So we actually knew what is missing in the database or what should be improved. Because without using it, it's really difficult to discover whether you made a mistake in the schema by forgetting to import one kind of data or by not formatting it properly so that you can join the table. There's some work about importers that still needs to be done. So the first one is to import a wanna build, which should be a few hours of work at most because there are dumps provided by wanna build. There's also a Brittany, it would be nice to import so we know why a package didn't migrate to testing. And the MIA status of maintainers, so we know who is MIA. And the big thing that needs to be improved is examples and documentation. So I hope that I will find a victim today that will come to me and say, OK, I'd like to work on that. Because the point is, it would be really nice if someone quite new to UDD would do that. Because it's a really nice way to learn about UDD. So currently, we have some examples on UDD.dbn.org. But the general output is really ugly. So it's just text files. I need to go to the source to see the query. So it's just a matter of improving the rendering of all of this page. So to contact people about UDD, you can use ISE on dbnqa or the dbnqa mailing list. And that's URL where you find more information about UDD. Thank you. So any questions, comments, things that we forgot that we should import, stuff like that. Any victims that would like to improve? No, one remark, I really like this DEHS import, which is quite early new. But I just learned that the permissions are not correct. So I couldn't select from this table. Yeah, to select. Thank you. Anything else? So it depends on the data source. So, for example, for source season packages, it's a date twice a day for squeeze season experimental, once a day for older releases. For Ubuntu, it's also once a day. For various simple things like DHS, Popcon, Lintian, all it's once a day. Debian bugs, it's four times a day. Test immigration is twice a day, because we need rents twice a day as well, I think. And basically it's once a day for most, except when there's a good reason to update more questions. That one or the HTML page? The numbers don't match the Popcon numbers. They should. This one matches, no? Yeah, there's a small difference. Yeah, it's about the same, but it's slightly different. I don't know why. And maybe the, yeah, strange. I'll check. I checked that all the package, all the orphan package have a Popcon value. That's why I didn't use left join in the query, because, but, OK, maybe there's a bug. I don't remember how it works. Actually, no, that's not the one. So, it gets this file, I'll check, but maybe this file is no longer updated. Popcon was moved to another host, so maybe there's something broken in the process. OK, I'll check. Other questions? Can you think of something that we don't import yet and that we definitely should import? Oh, I'm impressed. OK, thank you.


So, I'm going to talk about Ember and Oof, and in many ways this is kind of a tragedy, and I'll get to that later. But so I'm Matthew Rudy, and this is my logo, but it's actually just an emoji, but I've just changed colors. And I'm currently working on Chronicle in London, which is like a backbone front end, and like a load of ruby, and potentially in the future we're going to move to like Go and like Asandra or something, but we're basically a start-up, we're going to launch kind of next week, and we're always looking for, they're always looking for developers. So what are we trying to do with Oof? And I think there's sort of two things we want to achieve. One of those is like authenticating via a third party, it's the classic sign up or sign in with a third party. Because we don't want to handle passwords, because passwords get leaked, right? But we may also want to like obtain access to a third party API, and that was actually what I was trying to achieve when I was working on this little project over Christmas. So the tool, which is of course Oof 2, has its own logo, and has now a finalized specification but you've probably read about Oof 2, and particularly like the Road to Hell, described by the former author of The Standard, who quit a short while before it was published. So he explains his reasons for disliking The Standard as it turned out, and a lot of it was kind of like movement towards like corporate standards, but then at the same time people say that it doesn't really match the standards the corporate world needs. But actually, I think it's all right, at least for my purposes, and the spec is actually very readable, it's actually very simple, and maybe that's the problem is that it's too simple, and it's too many ways to interpret it, but fundamentally it provides four different flows, or four different grant types, which are the authorization codes, like the implicit grant, the resource owner password credentials grant, which is just like passwords, and the client credentials grant, and the spec has these very nice little flow diagrams which if you don't know what the resource owner and the fact is basically like someone is giving us, someone is using a browser, we're redirecting them to GitHub and then they're signing in GitHub and then it comes back, and this is the classic Oof situation, Oof 2 versus Oof 1, it achieves the same thing, like there's specific things about security, and Oof 2 particularly doesn't really provide any security, it says use HTTPS, but like this is, oh, so what actually happens is we get back parameters, which is an access, it's an Oof code, that we can then communicate via our secret on a server with GitHub who gives us actual access token, so it's so important, this only works if you are a secure server, because that's just how it works, but as well as giving us a token to use GitHub, we're also basically authenticating their identity with GitHub, which is the way that actually I use Oof most of the time is like Omni-Oof and I'm basically logging in, and this is the only flow that really gets you that, but what I was actually excited about and wanted to play with was the implicit grant, which in this case is the client, as the spec describes it, could well be amber, because it doesn't require any secret conversation between the client and the server, and in which case we don't necessarily have to believe that the token works, because the user is basically just trying to access GitHub, and if they have a valid token and GitHub is given it to them, then we can just use it, but importantly this actually uses the hash of the URL, and the reason is because we're trying to be secret for the, it has a very strange name for this, they call it the web hosted client resource, and importantly in this grant type we're trying to keep the token secret from them, and I'm suggesting that we probably want to deploy to S3, but the way that browsers work is that hashes are not sent to the server, but like Amber could definitely read this, and we could then just use that token straight away and access GitHub's API, and the third type is passwords, the password grant, which does what you expect, the user gives you a password and you hit an API and it just gives you back an access token which we can use directly, and the fourth one is like the client credentials grant, that as far as I see it's basically for servers to communicate with servers that are both in each other's trust, or I think that's the password, password authentication, or administrative interfaces. Yeah, from what I've seen I can't see, it's really for like servers using OAuth as like a standard to communicate amongst themselves, but so implicit grant flow is what you want to do, and there is thankfully an Amber OAuth 2 library that implements this and it's pretty well maintained and the config looks just like you would in like sort of Rails app with omni-auth. We're just going to give it a client ID and there is no secret, like in a server side you'd always be giving a client secret, but there is no secret because we can't trust the client. And importantly like this whole thing is basically that we have to create a state token that proves that when GitHub comes back to us that it will be the request we made. But importantly like they actually open a, the thing I don't like about this library is that it opens a new window which inevitably causes like pop up warnings and it doesn't work unless you accept them. So then this works. You see the examples in GitHub and there is a little trick here. So just using this is just like initially in your orphan you'll get the pop up warning and ignore it and eventually we'll get to, oh, I'm in the past. And this is something I think is quite cool is that GitHub is still not responsive. So if you have like a little window with a login form it just, I think I even moved it in this example, but like it just doesn't look good. Like GitHub need to kind of sort out their responsive login forms. But basically we get like a token except we don't because this actually isn't the implicit grant. Even though we asked for it, GitHub only actually supports the, so we're expecting to see, we can get like a parameter but actually we're supposed to be getting like a token. So GitHub doesn't actually support the implicit grant and they don't, well the documentation doesn't say they do, but I would hope that they'd just give me an error rather than looking like it was going to work. So basically they seem to ignore the token type parameter. So I spent ages like looking at this and then realised it was a total waste of time. But as I said, GitHub actually says you should use passwords. So kind of ruins my whole plans.  And from what I can work out, like Google does do it. Facebook sound like they do it. And there's probably other parties, but like actually I want to get GitHub. So my only solution if I want to stick to like a pure client side approach is to use passwords, which is what I didn't want to do. But I'm mostly like a Ruby developer. So I could just set up like a really simple omni-off server that just did this. So what about a hybrid approach? So what I think is cool, and I have like written a bit of code, but I haven't really finished it, is the authorization code flow but as an API. And like Ember and Rails, I love each other, right? So it's not going to be a problem. So let's take the authorization code flow and let's stick Ember in the middle of it, between the server and the web browser. So the concept is basically this. So in building like client side apps with like REST APIs, like we do this all the time. So like Ember should be like getting like an OOS slash new root, which should return like a URL to redirect to. And then Ember can redirect the client like storing state before it does. And then like get the callback and because we now have query parameters, we can actually in an Ember root, we can eat that up and do something with it and send it back to the server with a post. And I don't know if OOS is the best path, but that's what I'm thinking right now. If anyone has a better solution for like the name of this root, then please, please let me know. And then ultimately we're going to pass that code and the state object as well, I think. And we're going to end up getting like a JSON response that gives us the access token. And then we can do what we want to do. So I gave it big thumbs up. So like, so this is my hack together like version of it that probably doesn't work, but looks like it works. So like all we really want is just a simple like promise based Ajax client that gets a new token or gets a request for a token and then once we get the response, accepts it and gives us the get have access token. Now there may be something that does this already, but it's so simple it doesn't really need something else. And thankfully we can actually just do it in almost no code in Ember given we have query parameters because all we care about is that code, the code value that comes back, the state value that comes back and that's it really. So it's easy, right? So basically when I did this I thought like I was going to build like some really cool like github Ember app, but then I got sidetracked all the time. I'm trying to work out like this whole thing and then I realized it was a waste of time. So thanks. Any questions? Why which bit? You're sort of using trying to construct an API using a service. I don't know why I'm not using the service to handle those requests for you as a proxy to the Ember app. Why try to get the token into the Ember app? So what I want to do is build a like Ember interface for like Jekyll. So I want to basically like in the client I want to be interacting with the API. So all I want is a token. And going by the service doesn't make any sense. Well it doesn't make sense but it's unnecessary. So the way I have tried it before is either hosting the Ember app out of a Rails app and like setting a cookie and that's the easy way. But like I'm trying to get rid of cookies, right? So that's the easy way. Basically just use OmniOrph, set a cookie for domain and then redirect back to the Ember app and it would just work. But I'm trying to avoid that. And the other way that I do it, like my client does it right now, is that we have a separated Ember app and a separated like API server. And what happens is that we do an OAuth request and the callback URL actually is the API server. So GitHub goes back to the API server and then gets a token there and then redirects back to the Ember app, well it's a backbone app, with the OAuth token in the params. And that does work. But then like, I mean we are using Rails in a very similar way but I think it's an unnecessary step and I like building it up. So it suits me. And it's a valid question. But for my purpose, what I just want is like an OAuth token in my Ember app so I can like do cool stuff with Markdown. Yeah. Not a question but I ended up doing something similar. I've got an OAuth server that implements OAuth itself. So the Ember app authenticates with the OAuth server through plus it grants. And that authenticates with any other GitHub. Okay. So you log into the OAuth server and then the Ember app goes into that.  That's the other way to do it. So then you can just implement a grant on Ember app. So that's kind of a thing. That's a good question or a question. The implicit grant for that loose case, I would have thought that would be a case where you'd use your credentials and then it would just be more standard to part. With our app, you can log in with Facebook, LinkedIn, Twitter or user and password. And all that's kind of held on the OAuth server. And then we authenticate with that, get back an OAuth token. And that OAuth token we then use against our API server and the API server. And the OAuth server both talks the same database so that's all stored there. But all the Ember app has to care about is the OAuth token at that point. I don't know if I've answered a different question. Yeah, well it's probably a conversation for viewers. So I do have a question. I'm not sure if it's a fair question and it's sort of not really Ember related, but it's OAuth related. You brought up the fact that that library that's been used and I haven't seen it before, so I'll have to take a look. And how does this annoying pop-up function out at the end? And the smoothness of which you can authenticate. I've seen a few cases where it really works well. And when it works well, it's just a million times better. And then you can go back to the process. Is there a way to avoid that? Is there a reason technically? Why? I mean, it would seem like this would be an obvious change. Yeah, I think the only reason is because I haven't spoken to the author. But I think it's probably because they're building apps that don't use push date. So at that point, if you're using the hash for your routing, then using it also for picking up the OAuth token maybe doesn't work. That's my only guess. I haven't spoken to them. So actually, the way I approach writing talks is I always have this ambitious project that I start and then I realize I should just build a smaller library and then I realize I should stop doing that and do something else and then I achieve none of it and just give a talk. But I tried lots of different apps, right? And one of them, I basically took that Ember OAuth2 app client and just reused it using the hash directly on the URL and it does work. So I think a simple pull request and an alternative flow for using that would be really simple because the library's always there. Importantly, it knows how to store the token state, the state objects. So it already knows how to parse the parameters and such. So it would be fairly simple to do. I suggest just doing a pull request on his project and giving two different approaches. Okay, one more question. Do you think they're going to sort it out as the client side for a lot of the work? For the GitHub? Yeah, for any of those services because it doesn't seem to be a priority. No, it works a lot in cases. I think where you have, especially data that's not as potential to use easier use case to open up like last FM would be supported, for instance. You have Facebook definitely does and you have, there are a lot of different cases where the implicit grant works. And I think that there would be an interesting use case where if you wanted to, you're back end server, and I think if you have a back end server, you're probably considering having a hold of the secret there and you can do a lot more. At least they'll provide more services for you anyway as much as it might be more of a push real time service than a pull request reply. But the interesting thing would be to have your client basically get forward captioning. Just basically have it pull out a bunch of raw data, process that data, and then the interesting data that you care about gets sent back down to your server, to this work there. That would be, I mean, I've thought about doing that. I haven't had the time to have a pet project. So I don't see any good reason why I haven't done it apart from just it hasn't been a priority. Because, I mean, they already will give you a token if you give them a username and password. So why not, if you've authenticated by their system directly, it's more proof that you're the person. Maybe that's the answer. Maybe that's the answer. Raise an issue on the GitHub API repository. Cool. Thank you.


What's up guys my name is Michael and welcome to my YouTube channel today I'm going to go over how to reverse a link list and this is I'm going to do it recursively where you're returning the node actually every time. So I know this is like pretty difficult to think about but bear with me. So let's say we have this link list of three two and then one right. And this last one goes to null. So I want to you to basically return the reverse of this. So this should become one then two and then three and then three goes to null. So how would you do this? Well, first of all, if we're going to do this recursively, which I'm going to teach you guys how to do it recursively because generally this is how they want you to do it in an interview. This is how you would do it. Okay. First of all, let's think about what would our base case be? Well first of all, we're going to repeatedly go next to the next node recursively. So all the time I'm just going to keep going to the next node over and over and over again, recursively calling this reverse method. And during this time supposed to reverse the link list. Now, if I'm going to do this recursively, what would my base case be? Well simple. If I'm going to keep recursively, we're recursively calling this function, I'm going to reach the endpoint. And what is the endpoint? The endpoint is when my current node, if I'm going to keep recursively going to the next function, so I keep going to the next, the next node, the next node, right? My end function is when my node is in all okay, whenever I've reached the end of the list, I just return null. Okay. Right. When I reach the end of list, I'm going to return null because that means I'm at the end of the list. Well, but what is my other base case? My other base case is that let's say I'm reached from if I keep going next three and two then one is when I reach this one, it's when the ones next is null. Okay. And the reason why is because at this point, we're only at one node left. So we're just going to return only one, like we're going to return the node here, because we have nothing else to do at this point, that you can't do anything here. Right. At this point, the reversal of one is just itself, right? There's nothing to reverse. There's nothing to reverse here. And also the, the reversing, trying to reverse this null, let's say null, it's the last one. Right. The reverse null null is just itself. So that would be the base case, right? Is when you keep reversing it over and over again, you're just in the end, you're going to get like what one or no, okay, that's at the end of the list. Okay.  What do I want to do? Let's say I'm going to recursively call this function. So what is this function going to return? It's going to return one, and then this function is going to return the rest of the list. That's, if you think about it, let's assume this function works, right? Let's say I just have this function, and it's going to return the reverse of this link list. So what do I do in order to reverse this link list? Let's think about it. If I have a function that returns the link list reversed, what am I going to do once I reach this one, right? It's simple. I'm just going to point this one to the reversal of the rest of the link list. I know this sounds crazy, but think about it. If I'm at this last point of one, right, I'm at this point of one. I want to reverse this link list, right? And this function returns the link list, the rest of the link list that is reversed. Right? What I'm going to do is I'm actually going to point this function, this one, it's going to point to the rest of the list. Yeah, reverse, it's going to point to the rest of the list, reverse, right? Basically, this one, once I reach this one, this one's next is going to point to the rest of the list, the reversal of the rest of the list, right? So what it's going to do is this one here, when I reach the end of this one, I'm going to point this next, the one's next is going to point to a function that's going to return me the reversal of the rest of the list. Right? Do you think about it? Like this one, if I have a one and I want to return one, two and three, right? I have three, two, one. I want to reverse it. I want to get to one, two, three. Then what's the... What do I do? Assume that I have this function that is reversed, that can reverse the rest of the list. Let's assume it works. Well, if it does work, then one's next is going to point to the rest of the list that's reversed. Right? Think about it. Right? This one's next is going to point to the rest of the list. That's reversed. Okay. So now that's easy, like we just got that out of the way. But now what happens to the rest of the list when we get to the end? This is a little tricky. Let's say I'm at this point where one's next is going to point to the reversal of two, three. Right? And then two's next is going to point to the reversal of three and the end point. Right? The end of whatever was. But let's say I get down to two and three. What do I do at this point when I only have two and three? Right? I have two and three. What do I do at this point? Well, one's next is going to point to the reversal of three, three and two, right? Three and two. And it's going to reverse three and two to become two and three. What I do at this point, if my current list, while passing in the rest of this list of three and two, my head is going to point to here. Right? The list's head, the head is going to point to here, right? And if I'm going to reverse this, how should I do this? Like, how would I reverse this? Well, it's simple. Three's next, next is going to point to three. Do you understand what I mean? So this three, three's next, which is going to be two. This two is going to point to three. Now I want to change this two to two's next to point to three, right? Think about it. That's what I want to do. Three's next, next, three's next is two and two's next is one currently. I want to change this so this three's next, next of this two is going to point to three so it's itself. Now what do I do at this point? Now I want to change this three's next to point to null. Do you guys understand what I'm doing? Okay. When we get down to the bottom of it, this is what it's doing. I'm basically rerouting these links or to get myself. And then after this, I'm going to return this one. So then the end result would be one, two, and then three, and then three becomes null. Right? It would be one, two, three, and it becomes null, okay? So yeah, that's basically the gist how you would do this. Once you get down to the bottom of the base case and when you get reached the end of it, your list's next, next has to point to itself of the list and your list's next has to point to null. Once you get down to it, and while you're recursively calling this, you have to recursively call this function while passing in the current node and it's next is going to point to that, the rest of it. All right, I'll show you guys the code now. Okay. So the base case is that I'm going to basically we have list list, this node, this should be called head, a list list, this should be called head. I don't know why they call it list list, it just makes it more confusing. But this is the head of the link list. So the base case is if it's equal to null pointer, or my next pointer is equal to null, then I return my head, okay? The reason why we do this is because think about it. If we get back down to this point, we'll reach the end of the node, right? One's reversal is just itself. And null's reversal is just itself. That's why one's reversal is just we're just going to return the head of it. Now otherwise, let's think about this. I'm going to take my current node. I'm going to assume this function reverse of the rest of the list is going to give me the reversal of the list. Okay. So, so think about this. I have a function, let's assume this function works. Okay. Let's assume this function works. Reverse is going to give me the reversed link list, okay? And that's going to be my current node. That's going, that's definitely going to be my current node. This function current is going to be my new head now, okay? This function current is going to be my new head that I'm going to return, okay? This current function, because it's going to give me the rest of the link list that's reversed. Now, once I get to the bottom of the list, when it's down to two nodes, the list's next, next is going to point to the list. And that's this point, okay? That's this point. I'm going to, I'm going to clear this real quick when I, I'm going to select this and then select all I'm going to clear it real quick. So if we get down to the point of three, two, and one, right, basically this, it will boil down to two nodes at the end of this recursive call. At the end of this recursive call, this will boil down to two nodes. And lists next, this three, if I want to reverse three and two, how would I do this? I'll explain it again. Currently the head of the list is three. Three's next, next is going to point to three to itself. The reason why is because I want to set twos next to point to three. So then this becomes null and then threes next, I'm going to point to null, okay? That way now it's reversed. Now two is in front of three and three threes next is going to be null, okay? So I'm going to go back again and explain what I'm doing. Three's next is two. This twos next, I don't want it to point to one. I don't want it anymore. I want this two to point to three, right, to the head of it. And I want threes next to point to null. So in the end of this iteration, when we return two, it will be two, which is going to point to three, okay? That's the end of the list, okay? And then while we're doing this, we're recursively calling this function over and over again, while doing this same thing, reversing the links of the link list, every two of them. And then we're recursively calling again, and recursively doing this again, and doing it again and again and again, until we get to the reversal of the link list. And yeah, this code passes all the test cases. And that's basically just of how to reverse a link list. I hope you guys enjoyed this video. This video is pretty tough to explain. I know it's hard to wrap your head around this, but yeah, bear with me. Yeah, rate, com, subscribe. I'll check you guys later. Peace.


Proper maintenance of roads is necessary to preserve your nation's highway network and reduce transportation costs to keep the roads in good condition. It is very important to perform proper maintenance when it is first needed. Understanding the causes of common maintenance problems produces a better understanding of the repair tasks. Proper repairs made on a timely basis will prevent further deterioration, requiring more extensive and costly repair. This videotape focuses on common maintenance problems and causes. As the foreman, you must understand the cause of a problem before you can plan the proper maintenance operation. We will show you common maintenance problems and their causes for seven maintenance areas. Asphalt pavement, Portland cement concrete pavement, earth and gravel roads, road shoulders, drainage facilities, bridges, and roadside areas. For these seven maintenance areas, water causes most major problems. Water which is blocked by debris in drainage facilities will saturate the base and subgrade material. If water does not drain properly, it will enter the road base through surface cracks or holes and damage the base, subbase, and subgrade. A saturated road will deteriorate further until it is properly repaired. Another major cause of road damage is the weight of vehicles. Repeated excessive heavy loads will produce defects in all types of pavement. Also insufficient compaction of pavement courses causes the road surface to deteriorate quickly. If the pavement courses are not compacted adequately, surface defects will develop. If poor quality materials are used to repair the road, the repairs will not last very long. If defects are not treated while they are still minor, they will become serious problems. We will take a closer look at problems affecting each of the seven maintenance areas. Also, we will see their specific causes. Asphalt concrete pavements and surface treatment pavements have similar maintenance problems. Over time, vehicles on the road will make the surface aggregate smooth, creating a slippery surface. The loss of cover aggregate can be caused by using dirty or wet aggregate. It can also be caused by the asphalt cooling too much before the aggregate is spread on top of it. Or if the aggregate is not compacted immediately after it is spread. Bleeding is recognized as a shiny film of batuminous material on the pavement surface, caused by too much asphalt in any layer of pavement. Corrigations are recognized as a series of closely spaced ridges on the pavement. Corrigations result from the paving mixture having too much asphalt, too much fine aggregate, or aggregate that is too round, as well as asphalt cement, which is too soft. Ruts are surface depressions developed in the wheel path. They have the same causes as corrugations. Poor compaction and poor quality materials will cause shoving, which occurs when a specific area of pavement has been permanently displaced under the weight of vehicles. Depressions are identified as pavement areas that are slightly lower than surrounding pavement. Traffic, heavier than the pavement's bearing capacity, causes depressions. They are also caused by settlement of the lower pavement layers, or by poor construction methods. If any of these hazardous surface defects are not corrected, cracks or breaks in the pavement may develop. Cracks are also caused by inadequate support of the road base. Pavement, which is too thin, shrinkage of surface materials, the age of the pavement, or by poor quality materials and construction methods. If water saturates the base and the subgrade through these cracks, potholes may develop. Also, if depressions in surface treatment and asphalt concrete pavements, which are caused by a weakened base, are not repaired, or if water has saturated the base, traffic will cause potholes, by helping to break up the weakened pavement surface. If water continues to saturate the base, subbase and subgrade, the whole pavement structure will fail. When this happens, the subgrade, subbase, base and surface must be replaced. Let us look at problems associated with Portland cement concrete pavement. Common types of failure in Portland cement concrete pavement are polished aggregate, caused by repeated traffic, reduces the friction necessary for tire adhesion of vehicles. Cracks are caused when the concrete shrinks due to improper curing, or when the subbase or subgrade expands due to water saturation. Also, heavy vehicles on poorly supported slabs will cause cracks. Scaling is the peeling away of the pavement. Scaling results from the use of de-icing salts, improper mixing or curing of materials, or the use of unsuitable aggregate. Scaling is the breaking or chipping of the pavement at joints, cracks or edges. Scaling develops when gravel becomes lodged in a crack or joint, when there is poor installation of load transfer devices at the joints, when there are poorly formed or sawed joints, or when weak mortar is used in construction. If scaling and spalling are not promptly repaired, they may become holes in the pavement. The combination of heavy vehicles and a saturated subbase or subgrade will cause pumping. Pumping is the concrete slab movement along joints and cracks under passing traffic, resulting in the ejection of a mixture of water, sand, clay and silt. If not repaired, pumping may cause faults. They are recognized as a difference in elevation across joints or cracks. This defect is also caused by an insufficient load transfer between slabs, as well as shrinkage of the underlying course. Earth and gravel roads have different problems than paved roads. However, most of their problems are caused by water. Also, heavy vehicles and wind will erode unpaved roads. Loss of the roads crown is the most common problem on unpaved roads. Corrigations, ruts and potholes are other serious maintenance problems on unpaved roads. Gullies are caused by water running on the road surface. Soft spots on unpaved roads are low areas where water accumulates and saturates the subgrade. This weakens the road. Soft spots must be repaired to prevent serious damage. Let us look at problems and their causes for road shoulders. Paved road shoulders have the same problems and causes as paved roads. They may be deteriorated due to a loss of cover aggregate, cracks or potholes. Earth and gravel road shoulders have different problems than paved road shoulders. Water and heavy vehicles cause problems on unpaved road shoulders, such as a loss of cross slope, shoulder drop off, erosion gullies and ruts. Vegetation growth and material buildup on shoulders will prevent water from draining off the road properly. Drainage facilities, which are not maintained properly, can cause many problems on all types of roads. Water, which cannot drain through drainage facilities, causes serious problems, such as cracks and potholes in paved roads and ruts and soft spots in unpaved roads. Poor drainage may be caused by unlined ditches, which have a cross section that is too small, a loss of shape, collapsed sides or accumulated debris and vegetation. Lined ditches with damaged linings or accumulated debris also cause poor drainage. Culverts restrict the flow of water by having their inlets, outlets or their interiors blocked by debris and vegetation. Also, breaks in the culvert will weaken the surrounding area and may cause the road to wash out during the rainy season. Catch basins filled with silt and debris inhibit proper drainage and cause water to accumulate on the road. Also, cracks in their structure will allow water to weaken the surrounding area. We will look at maintenance problems and causes associated with bridges. Concrete bridge decks have some surface problems and causes similar to Portland cement concrete pavement. These similarities include cracking, scaling, spalling and holes. However, bridges have unique problems as well. Exposed and corroded steel on steel bridges weakens their overall structure. Loose planks caused by inadequate nailing on a timber bridge deck are a safety hazard to traffic. Rot caused by aging or improper treatment also makes timber bridges unsafe for traffic. Accumulated debris on bridge decks can block drainage holes and expansion joints. Also, accumulated debris on the bearing areas of abutments and pier caps will prevent the bearings from functioning properly. Debris will accumulate under bridges, restricting the flow of water and endangering the safety of the bridge structure. High water current and accumulated debris can cause erosion around the abutments. And last, roadside areas present several maintenance problems for roads. Overgrown roadside vegetation will hinder proper drainage and may obscure the visibility of road signs. If water seriously erodes an embanked section of the road, the road will become weakened or may be partially displaced. On unstable slopes of cuts and embanked sections, slides may occur during the rainy season. Remember, water, heavy vehicles, poor construction and maintenance methods, and poor quality materials cause most common maintenance problems, which include cracks, depressions, and potholes in asphalt pavements. On Portland cement concrete pavement, these problems include cracks and spalling. Major problems on earth and gravel roads include corrugations, ruts, and potholes. The most common maintenance problems on road shoulders include erosion gullies, shoulder drop-offs, and vegetation growth and material buildup. Debris in drainage facilities such as ditches, culverts, and catch basins are responsible for restricting the flow of water. The major problems on bridges include surface defects, blocked drainage, and bearings blocked with dirt and debris. The most common problems in roadside areas are overgrown vegetation, slides, and embankment erosion. The IRF training aids will help you make the best use of your workers, equipment, and materials to repair these problems and maintain your roads properly.


And also following the trend, the governor Peter Mbao of Inigo State has also signed the 521.5 billion Naira in Inigo State's 24 budget into law aiming for disruptive economic growth, radical infrastructure development and efficient service delivery. The operation law consisting of 414.3 billion Naira companies per each and 107.2 billion Naira revenue. We heavily rely on the Internet of Generated Revenue, IGR, and bad thing that the United States members for their support and pre-executive legislature collaboration and the budget estimate. The signing signifies the first time in the state history that over 400 billion Naira will be spent on a captive project 20 times more than usual. It is required because we called this budget a budget of disruptive economic growth and it's disruptive based on the reasons I've already given. The first time we're spending this size on our Capex. It also means that we're going to have huge economic activities in Inigo State. So imagine an economy that is typically used to the spending of 20, 30 billion as Capex, now going to witness a spend of 400 plus billion on the same Capex. That is going to be monumental. In the way that it leaves our people out of poverty, in the ways that we generate economic activities, most importantly it is also going to ensure that we address some of the gaps we have in our social services. So for us in the education sector, the passage of this bill and the signing of this bill into law today is that we're not looking forward to 260 smart schools in all the wards in Inigo State. Hello, hope you enjoyed the news. Please do subscribe to our YouTube channel and don't forget to hit the notification button so you get notified about fresh news updates.