The Cube at Hadoop Summit 2014 is brought to you by Anchor Sponsor Hortonworks. We do Hadoop. And headline sponsor, WAN Disco. We make Hadoop invincible. Hey, welcome back everyone here. Day three coverage of SiliconANGLE, Wikibon's The Cube, our flagship program. We go out to the events, just trying to see the noise. Wall-to-wall coverage, I'm John Furrier, my co-host. Jeff Kelly, big data analyst at Wikibon. Jeff, day three's kicking off. Let's get into the analysis. What's your take? Two days of meetings, talking to executives, entrepreneurs. And we've seen three levels of interest here. The startups, the growing companies, and also the big public companies. So in each one, there's a lot of activity, a lot of biz dev, a lot of new products. What's your take? Well, a few things. One, I think some of the conversations I've had here are kind of validating some of the data we've been collecting at Wikibon around the adoption of Hadoop. And really, I think what we're seeing here is we are very close to a tipping point where a lot of the kind of early adopter, POCs and experiments, blossom into kind of full-blown production deployments. We're getting very close to that point where Hadoop goes mainstream. We just saw this morning on the keynote panel, companies like Kohl's, talking about their use of Hadoop. So it's being used much more widely than just in some of the valley companies. So that's a good sign for sure. I think one of the other big topics here over the last couple of days has been the Hadoop and the data warehouse and how they interact and how they relate to one another. Do they complement one another? Will Hadoop replace the data warehouse? And it's really interesting, particularly from the vendor perspective. There's 88 vendors here. A number of them are the data warehouse heavyweights that are household names. And it's really interesting to watch the different companies try to position their technologies relative to Hadoop. Some are kind of tying themselves and not trying to do that. Others have a more elegant story depending on their technology. So those are two of the big stories. And the third, I think, is of course some of the capabilities around Yarn and SQL on Hadoop or in Hadoop, depending on which nomenclature you prefer, making Hadoop go real time. And that relates to what I mentioned earlier about it. Just about ready to go mainstream. So Jeff, you had a good show here. Obviously you had a great presence on stage, Merv Adrian and yourself, Jeff Kelly from Wikibon, headlining the keynotes. Talk about what you did on the panel and then I want to talk about the survey that you've been kind of leaking out a little bit here. So let's talk about your keynote on stage with Doug Cutting, the inventor of Hadoop and Arun Murthy, lead tech guy at Hortonworks. Really the players behind, the tech athletes behind Hadoop. What was your agenda, what did you guys talk about and what was the walk away from that? Well the main theme of that conversation was about where is Hadoop going, what's the future of Hadoop and who better to provide their input and their insights on that than really two of the most important people in the community. Doug Cutting, who essentially the founder of Hadoop, the father of Hadoop, founded the technology and the approach back at Yahoo. And of course Arun Murthy, who worked with Doug at Yahoo who created Hadoop too or Yarn, which is essentially enabling Hadoop to again go mainstream and be more applicable to different use cases. So it was a really interesting conversation. We talked a lot about how to keep the community vital going forward over the first, about nine years of its lifespan. I mean the first half of its life, there were no commercial vendors around the Hadoop space. It was all the community. Then there were some startups that started getting involved in recent years and now you see all the big companies here, Microsoft, Interdata and Oracle, SAP, they're all here. So we talked a little bit about how that's going to impact the development of the platform. And they're positive and positive and negatives. There's a lot of money flowing into this market from those companies I mentioned, also VC firms. Money can be a good thing in that it spurs development, it spurs interest, it shows that really Hadoop is becoming a critical part of the data infrastructure and it's going to be in the future. But of course when you've got different competing interests from the different large vendors, that has the potential to take Hadoop in different directions that maybe might not fit with exactly what the open source community might be interested in. So we talked a little bit about that. And it's a balancing act. I mean there's no definite answer how that's going to happen, but it's important to keep the community aspect vital, I think is really critical for Hadoop to become all that it can. And then going forward we talked a little bit about where they saw Hadoop in five, 10 years. And not surprisingly they really see it as a mainstream part of the data center. And it's going to take its rightful place alongside other technologies. So the Wall Street Journal is an article today from your panel, so good job, congratulations on really generating the kind of attention on a global scale. Wall Street Journal talking about your interview, but also they bring up a good point which is the skills gap. Talk about that. What did those guys talk about? I mean it's new generation of computer science programmers and developers and architects are coming into the market. What was discussed there? And why did the Wall Street Journal focus on that panel so much? Well, famously McKinsey pointed out a few years ago in their big data study that I think the number was we're going to be short of about 190,000 data workers, whether that's data scientists or application developers, whatever the case might be. So this has been a theme or a meme going around in this community for a while because Hadoop is a complex technology and in its earlier form you really needed some particularly advanced skills to work with MapReduce and Program and Java. And these were not skills that were widely available. When you think about the data science level being able to combine the statistics capabilities, the math capabilities, and as well as more of the business acumen which you need to be a successful data scientist, there are not a lot of those people around. So that is kind of the main issue that we've been kind of grappling with in that sense for the last few years. And one way I think we're going to overcome that and we're starting to overcome that is one, the tools will get easier. They'll abstract away some of the complexity. But the other thing is, as Doug pointed out in the conversation, the younger generations coming up through universities now, they are being born into this world where they're comfortable with Hadoop and MapReduce and they understand that data, being data savvy is critical no matter what your line of work going forward if you're a knowledge worker of any kind. So as that generation comes up, that's one way we're going to close this gap. And I think that was Doug's main point. I like how the comment about they were kind of saying, Java might not be the young guns language of choice. I think that's true. We've said that on theCUBE many times. It's a great panel, great keynote panel with those two legends in the industry. It's fun watching the industry grow up with those guys. See, there's normal guys doing their thing. Now they're celebrities. Yeah, well, I know it's interesting too. I mean, there was always, there's this subtext of, you know, and I think people were wondering, we have got Hortonworks and Cloudera on stage together and there was a joke going around in the green room which we should have got those sumo wrestler outfits for the two guys. I wanted to make sure in that conversation that it was not a vendor food fight because these are two, they do represent their respective companies, but they're really, I think, even more important members and leaders of the community. So I wanted to kind of keep it on that level. I mean, Doug Cloudera, you know he works for Cloudera. It's very clear he is pure open source guy. He's not one of these guys that leans to, plays his jersey with his team. He is pure community guy, and Arun, obviously being one of the co-founders of Hortonworks is all about the open source. So those two guys deserve a lot of credit, independent of the companies that they work for.  So Doug and Arun, fantastic people. It's great to follow them and see their work get recognized on a global scale. Next question I want to ask you is the survey that you're showing people that hasn't been released yet. It's coming out, the exclusive Wikibon survey that you put together, okay, narrowed down, very targeted, what are some of the results there and how is that playing out? What's some of the feedback? Well, the feedback's been good so far. You know, we've been, as you say, kind of, you know, sprinkling in some of our insights from that survey on the show over the last couple of days and on Twitter. You know, we'll be formally releasing the results shortly, we don't have an exact date yet, but we're going through the results now and we will make those available to the community. But you know, some of the interesting findings, you know, I think relate to what we were just talking about the point I made about kind of being very close to this tipping point where Hadoop's going to start to go mainstream. And one of the interesting findings we found, you know, among Hadoop practitioners, people who have deployed Hadoop in their enterprise, only about 25% are actually paying customers of a Cloudera, a Hortonworks, a MapR, et cetera. Majority are actually using not even a free distribution from one of those vendors, but roll your own Apache Hadoop. So that tells me there's a huge opportunity there. I mean, I guess there's two ways to look at it. One, you could say if you're one of these Hadoop vendors, like wow, we need to do a better job, we need to start ramping up the revenue. On the other hand, look at that opportunity. And also keep in mind that our survey was probably a little bit more forward leading than a lot of the other analyst firms, some of their work, you know, we kind of deal with more of the cutting edge to technology and early adopters. So if you, you know, we're going to apply some of our statistical methods to this. And I think when you really take a step back, the actual number of the percentage of Hadoop practitioners that are paying customers is probably even lower than that. So there's a huge opportunity here. And if you couple that with all the talk we're hearing at this show about Hadoop being ready for the mainstream, that's why I think we were at this tipping point. Some of the other findings, you know, one interesting finding that we haven't talked a lot about at this show, hasn't been a real big focus of the show is the use of the public cloud to support big data deployments. Around 56% of the respondents to our survey who have deployed big data technology in one form or another are using the public cloud. And another 24% plan to use the public cloud. So that's an interesting, you know, we talk a lot about it, we keep on the convergence of cloud and big data, along with application development being agile. We don't hear a lot about it at shows like this, but I think that's the direction we're moving. And it's clear from our data that that's what practitioners are looking at. So what's your plans for the survey? Take us through your roadmap. You're going to take it on the road. You're going to publish it. What's the timetable? What's some of the activities around? Are you going to do follow on surveys? A lot of folks have asked me, one, where's the survey? How do we get my hands on it? And two, can you do more with it? Are you going to do more? Absolutely. So, you know, we just wrapped up the survey. So right now we're kind of going through the data at a high level. You know, once this show wraps up, my next big focus is going to be digging really deep into the data, doing a lot of cross tabulations and finding some of those really great insights. And indeed, we're going to take it on the road. We're going to be visiting a lot of the people in this room at their respective companies and kind of sharing some of the insights. And then we will, of course, publish on Wikibon some of the top level results so the community can get a look at that. And then I suspect we'll be getting a lot of inquiries from our clients to dig even deeper into the data. And that's something we plan to do. And then in Q3, we're going to do another survey. We're going to follow up on this. And that's really our plan at Wikibon is to kind of double down on our survey and essentially data collection work because we find that's what a lot of our clients are interested in, one of the communities interested in. Okay, it's day three. We're going to dig in a little bit deeper today. Today, day three is usually the day we kind of relax. A lot of activities kind of like trying to get the energy going here, but mainly we're going to dig into some of the deeper conversations around the three areas we've been exploring at this show. You know, the startup, you know, series A, B companies, the series C funded growing, rapidly growing ventures. And obviously the big whales, the public companies, all three of those theaters are really pumped right now and active, all doing well in business. We're going to have CEOs and CTOs from all three of those sectors coming in and sharing with us their insights, their experiences, their objectives, and how they see this world playing out in the Hadoop big data landscape. This is theCUBE. We go out to the events. I can see them from the noise. I'm John Furrier with Jeff Kelly. We'll be right back with our first guest, day three, right after the short break.


Open your eyes. What can you see around? Wind of the open sky Over the siren sound. This is a dream getting the royal scar Holding a diamond blade throwing in


So, again this is part of the bird's eye view I want to talk about hardware um. So, one thing to talk about is displays. So, again we have talked about screens for oh I should say visual. So, examples of visual. So, we could have screens like maybe going back to cathode ray tube monitors right. I think you are old enough to remember those at least right um LCDs, plasmas I do not know organic LEDs and so forth. And maybe you might want to involve lenses in some kind of optical system if you are making a head-mouthed display out of these um. You can get a little more exotic and do um virtual retina display um. There is a lot of work on this going on in industry a lot of it let us say behind closed doors. So, a lot of research a lot of prototypes being developed with virtual retinal displays essentially just take a tiny projector and just project images directly onto your retina, but of course they are still going through the lens of the eye. So, it is not exactly the same as you would think, but at least you are not trying to just simply look at some pixels and deal with whatever the relationship is between that and how it falls onto the retina. You are directly considering what information should be presented to the retina. So, that is one possibility um is also an interesting and exotic family of um displays called light field displays. You can research these on your own light field displays I will not cover these things. In this case um rather than presenting the information on as a two dimensional projection, they try to capture the entire field of light within a three dimensional region.  So, you capture the entire light field using something like say a planoptic camera array or some other kind of device it is also very difficult to do. And then present the entire information in some way so that um you can in real time take into account these small motions and present the entire light field. So, that is another possibility. And I guess somewhere in here I should have mentioned um let us say projectors I will put it up here by screens. In fact, I probably should have put it first um we have had movie projectors for a long time going all the way back to the beginning of film like the like the train pulling into the station from 1895. So, maybe projector should even be first there right um for audio. So, that is visual just think about displays again.  So, there are what are called haptic devices and um you know I will not have time to cover this these in the class, but um couple of general categories which are worth considering about is um cutaneous versus kinesthesia. So, nice way to divide these up um an example of the first one is maybe I just get some kind of vibration as a kind of feedback right a rumble pack in a in a in a game controller would be an example of that or maybe my emotions actually get blocked I feel a resistant force um there may be a robot on the other end pushing back at me right and providing the right force that feels like I am touching a wall I keep getting stopped every time I put my hand out right, but maybe a robot hand that is touching mine let us say um. So, that would be an example of kinesthesia. So, um so you can provide this kind of feedback as well um and as far as going into smell or taste or vestibular stimulation I guess I will not include too many examples of that, but there there certainly is ongoing research on those as well providing the right um um chemical feedback um to trick your your sense of smell or taste and there is electrical stimulation of the vestibular organ that is possible, but I do not recommend trying it. So, it is um very painful from what I hear alright um other hardware you might think about inside of hardware other hardware of course, we have computers on on use and we have graphics processing units let me just kind of you know just to kind of list off everything computers and GPUs inside of there. So, let us say CPUs and GPUs and I should also say that there are inputs and in this case um maybe something like a game controller keyboard and we talked about data gloves been around for a long time. So, a lot of interesting research and development going on on this part by the way input devices for virtual route is a lot of open work to be done there because once you put on a virtual reality headset it is like a blindfold and probably the last thing you want to be doing is just feeling around for the keyboard right.  So, how do you do that how do you enter data fast enough and in a comfortable way and interact with your environment is it going to be a keyboard and mouse or is it going to be something else um one more bit I want to say about hardware is what do we use for tracking. So, tracking is going to become very important as I talked about in the case of a head mounted display when you turn your head you have to get the visual information to update correctly. So, that it really looks like um the virtual world or this alternate world is responding appropriately to fool your brain. So, tracking becomes very important and the more portable the device gets or the closer it gets to um the actual sense organ the more kinds of tracking you need um if I am in a cave system I can see my entire body as I walk around right. If I put on a virtual reality headset and look down I do not see my body. So, I have to invent a body how do I do that well I can track my body and then bring that into virtual reality, but that is a lot of work it is very challenging. It is reasonable as a class project, but it is very hard to make it um 100 percent reliable and accurate. So, these things do not work very well they look great they make great demos, but very very hard to do that. You could put on a motion capture suit a full body suit with markers gets a lot better than, but if you are going to do that much work why not just build a cave system you know. So, it is a very interesting kind of problem. So, I want to talk about tracking and this will finish off the hardware where is my chalk ok let us see I am leaving it there alright um tracking. So, you call this tracking or estimation or filtering. So, people in electrical engineering will tend to use words more like that um one of the most useful components is the inertial measurement unit people call IMU. So, IMUs have been around for a long time they were originally designed for navigation um especially useful in aircraft and spacecraft. So, if you fly on if you flown on airplanes before almost certainly there was an IMU on board usually a rather large mechanical device um. So, the purpose is to provide orientation estimation. So, these are used for orientation orientation rotation if you want estimation right. So, that is their main design what it measures is 3D angular velocity and 3D linear acceleration. So, the um the angular velocity measuring part is usually called a gyroscope sometimes people refer to the entire inertial measurement unit as a gyroscope I think that is not quite right and this part is called appropriately an accelerometer. So, this measures linear acceleration, but it is also measuring acceleration due to gravity because there is no way to really separate true linear acceleration with respect to the fixed earth and gravity in a natural way there is no natural way to separate that you are always measuring the vector sum of those two it is as if we are all on a rocket ship right now accelerating that way at 9.81 meters per second squared which is why we are all stuck to the floor right. So, that acceleration is always being measured as well right. So, we have the inertial measurement unit the interesting thing that is happened in this technology is that our smartphones have IMUs inside mainly so that you can play these apps where there is a ball rolling around um or I guess it is designed so that it tells you whether or not the screen needs to be reoriented which frequently seems to fail and it very often fails because you are moving while orienting and this linear acceleration of the device is getting confused with gravity is all kinds of issues like that, but um these started appearing in smartphones they became very very cheap mass produced on the order of hundreds of millions and now you can just take those and put them inside of virtual reality headsets and you have an IMU to use and does not cost very much money at all right. So, it can be mass produced you can also put them inside of earphones as well. So, this is great you can stick them on robots you can put them all over the place to estimate orientation. So, that is one of the greatest enabling technologies and one thing that is very closely related to the inertial measurement unit and is sometimes considered a part of it is magnetometer which measures magnetic fields 3D magnetic field you can sort of think of it as a compass, but it is not exactly a compass it is going to measure the vector sum of the earth's magnetic field and whatever other magnetic fields are around in the building let us say or on the circuit board that contains the magnetometer. So, it is just generally measuring magnetic fields that is also used to provide orientation information. Other hardware um cameras have become quite useful you will notice on the the DK2 Oculus DK2 um used in the lab there there is a there is a camera. So, that is being used as part of the tracking system as well and when you use cameras there is generally two different kinds of ways of doing tracking the names are inside out and outside in um honestly I I got these I found it very confusing it took me at least a few weeks to to keep them straight. So, I I do not know, but these are the terms that are used um. So, in the inside out case you are this is a top down view you are wearing a headset and there is a camera on it here let us say and then there are some markers in the physical world I will draw markers as pluses features or markers. So, they see these markers and so, based on how these markers appear to the camera that is fixed to the headset you can figure out where you are at. These markers could be engineered or it could be using natural features from the environment. If you engineer them yourself then you get very accurate very reliable performance. If you just extract them automatically it makes a fun project, but it is an interesting demo maybe, but it is very hard to get perfect accuracy and reliability or very very high accuracy and reliability like this, but nevertheless either way this is inside out. The other way is outside in which is what happens in this Oculus Rift DK 2 case can you have the head looking straight down you have the headset on and then there is the camera out here looking and. So, these features draw them in another color here. So, we see them are on the headset itself. In the case of Oculus Rift DK 2 that you will use in the lab these are infrared LEDs that are embedded inside of the headset. The plastic is infrared transparent, but in the visible spectrum it looks black. So, you cannot see the LEDs, but they are inside of there. So, in this case it has markers. So, this is outside in other words the camera is outside looking inward and in this case the camera is inside the headset looking outward. So, these are ways to use cameras and we can talk about the technology of doing this tracking later in the course I will spend some time on that. And of course, you can add to the camera's depth information. So, you can have what are called you know including depth like information provided by the connect using current technology to give you what are called RGBD sensors right giving you color and distance information. So, there is cameras for that and those are going to be very important in the coming a few years as the cost of those goes down the reliability goes up the accuracy improves. There is going to be more and more technologies that use depth cameras for various kinds of tracking. So, you put all this together there is also more methods that use electromagnetic fields or magnetic fields that are generated by a base station and you can do tracking that way. One thing to think about throughout these tracking technologies is what do you need to track?  For example, I am giving a lecture today and I can only look at one of you at a certain at a time right. If we were all in virtual reality doing this lecture I could be looking at all of you at the same time that each one of you would see me looking directly at you right. So, you do not need to have my head tracked perfectly I need to have my head tracked perfectly I guess to have the display work correctly, but I do not need to have where my eyes are looking tracked perfectly in terms of what you see I could just make it so that I am always looking at you so that you are always paying attention to me and you get the feeling individually that you are being looked at, but really I cannot possibly be doing that. So, there is cases where you do not want to provide the exact information that is going on in the real world. So, you really have to think about these things carefully and there is always a cost involved and accuracy issues and comfort issues again. If you are tracking the body and it looks like my arm keeps breaking and bending in a backward direction that is not comfortable right it is torture of some kind right. So, if your system is not working reliably it is probably not worth doing or you have to assess is it really necessary. If it is then throw all the resources you have into it and make it work, but it might not be even though it might look cool might not be necessary. All right. So, that finishes the hardware part. I want to talk about the bird's eye view of the software. Are there any questions about hardware? Again this is very high level overview I am going to go into more details of these things. In fact, I am covering the fundamentals. So, by giving these examples you will be able to see more of why I am jumping into various fundamentals.


there my friend and friends. When you're learning CSS, you'll hear a whole bunch of best practices that you should follow that make your life easier. I talked about some of these, like I have a video that looks at why you shouldn't use m for font sizing and use rem units instead.  No matter what you're doing, you should always go mobile first and the list goes on from there. And the reason for that is I equated a little bit to like riding a bicycle with training wheels on it. So that way they can just focus on learning the mechanics of pedaling and steering and braking, I guess, and not worry about the balance. Then once they have those other skills down, you can take off the training wheels and really then start getting into what biking is all about. And of course, there's the opposite approach to it like balance bikes where the opposite is true. There's no pedaling. You're just balancing. But the idea is you want to focus on one thing at a time while you're learning and you're limiting all the different things that you have to learn. So you're not trying to learn everything at once. But we take those training wheels off eventually, right? Because if not, they're holding us back. If we're riding a bike with training wheels, you can't go as fast, you're trying to turn corners, it's actually easier to fall over. And it's a little bit like that with some of these best practices with CSS as well. So one example, there's what I just mentioned off the top with never using the m units when you're doing font sizes, because that's a very good general rule, especially early on where you can really run into issues with compounding and just fonts going out of control. But once you're more comfortable with CSS, and you understand more of the impacts of these types of things can have, then ms can actually be a very good tool to have up your sleeve to use in the right situation when dealing with your font sizes. So if you're past the very basics of CSS, and you're ready to take your training wheels off in this video, we're going to be talking about many of these best practices and the ones that we don't actually maybe need to follow. And sort of maybe the limitations of when we don't follow it the way they can get in our way when they do, and at least one along the way that we should probably stick to. Now the first one I want to talk about is using a class selector for everything. And the reason that we do that is because we want to have the same specificity for everything that we're doing. But there's, you know, some advantages to having element selector. So here's a very simple page, I haven't done a lot on it. But I am using my class selectors, I have a general body selector, I have the star selector here for my box sizing, my image as some of these you might see as like resets. But I am setting colors on my links. I'm doing a little bit of stuff with fig captions and block quotes and other things before I eventually start getting into having some classes for different things. And for me, if you're completely avoiding element selectors, you're going to be doing a lot more work than you actually need to do. Because by styling up things based on just their element selectors, you're setting the stage for everything else. And this is going to come back a little bit when I talk about why mobile first for everything might not be the best idea. Where the idea for me when writing CSS is you want to write the least of CSS possible to accomplish something. So like for me, it makes sense just put a link and set up my colors and my hover and all of that like this, then having to always have like a link class on everything when it doesn't really serve a purpose. And then if I do get to my navigations, well, there's other ways that I can style these that are going to be lower down in my CSS file and have higher specificity, because these are all super easy to overwrite because they're single element selectors anyway. Now the other one that comes up is people saying you should never use IDs as selectors and just use classes for selectors on everything. And this even could be where using an element selector could get you into trouble as well. So I want to sort of cover all of those things and talk about why class selectors can be a good thing at the same time over element selectors sometimes. But like right now I have this header here and I have a nav in there. And this is my only navigation on the entire site. So I could come in here and I could style that just by coming in and saying my nav and I could start putting styles on that and there wouldn't be a problem where this potentially could become problematic. And one of the reasons I tend to have a class of primary navigation on the one at the top of my page is because very often you go all the way down and you'll have a footer and in your footer you'll have another nav and the nav down here probably will be a little bit different from the one here. Often there's a lot more links and you have sort of a full site map almost in the footer nav or that's very common on certain types of websites at the very least. And I don't necessarily now again it depends completely on the context of the project you're working on but you don't necessarily want to have it so your nav is the same in both of them. So setting nav here could potentially be dangerous. So then this nav could be a class of footer nav right. So you have your primary nav at the top of the page. Let's just make that a bit bigger. We have our primary nav at the top of the page here and then we have the footer nav at the bottom and then I can select them with a single class selector. But if this is my only primary navigation could I come in here with an ID. And I guess you could. I'm the type of person I generally don't style things through IDs. I don't really see the benefit of styling something through an ID and I find well it generally will never get in the way if it's my only primary navigation. So using an ID would probably be fine. It's just one of those times where I do feel like this is raising the specificity for no good reason. So I tend not to do it and it just becomes a habit of using a class everywhere. And it is actually very possible that this navigation and the footer navigation end up being styled and looking almost identical. So maybe I'm actually going to use the same class in both places and then if it's an ID I can't use it. So classes for me are a little bit safer but that's not to say you can't use element selectors. Just be very aware of sort of the limitations of using them if you're going to use them. And by having higher specificity sometimes that's actually a good thing but you just want to be a little bit careful with it and be very thoughtful if you're actually going to be using one and not just using them all over the place because this is actually a mistake that I sometimes see is people using IDs quite frequently in their style sheets and then all of a sudden they have to sprinkle importance into them because they need to overwrite a class that they set somewhere else and things can get really messy really fast. So I do understand the idea of having ID selectors but I do want to caution just to be careful if you're going to do it and be very thoughtful and make sure you understand the implications of using an ID selector if you really feel like you want to use one. And that sort of does lead to the next thing that I want to talk about which is still in that same vein of the say we have my I decide to go with my primary navigation. So let's do that primary navigation right here and that's going to be along the top of my page right. So well maybe I want that area and that's my area here. So my primary nav I want to you know get this styled a little bit differently and I have my ul here and my li here and if you really go by the strict class selector for everything then I should probably come on here and do a class equals nav list and then I would come on these list items and I'd have a class on them of like nav item and then on all the links we could come on and do a class of nav link and by doing this you're just making sure everything has the same specificity so if ever you need to overwrite something it becomes very easy to do and I'll show you an area this could potentially get you into trouble in a way but I tend to do my primary navigation and then just choose the ul like this and then we can do a display flex and a list style none and let's add a gap on there one ram and it comes together and I you know this to me is completely fine and one thing people complain a little bit about when it comes to css is that css has this global nature to it where you're getting scoped css this is sort of scoped css I'm saying my ul that's in my primary navigation and then I could do the same thing where I could do primary nav navigation a and then on that I could come in and say that the text decoration is none and I can remove my text decoration from them and then maybe add them back on and hover hover or whatever it is but it's just you know this to me is in problematic even though it's boosting the specificity but that's okay because I sort of am running into this situation where these very specific links that I want to style differently anyway the one time this potentially could give you a problem if you did something like this is let's just say I said the color on these was I don't know green just so we see a change and for some reason you have a utility class so let's just call it color purple and I say that this has a color of purple and I need one of those links to actually have that purple color on it well I can't do that because if I come here and I do class is equal to color purple and it's not working and it's not working because this has a lower specificity than that one does so if I remove that now that middle one does get the purple style on there because these are both class selectors this one is coming second so that one wins so it's one of those things where you do have to be aware of that potential getting in the way if ever you needed to do something like that but to me you're probably not going to do something like that and then you could say well that's where you throw an important on there or something that's not where we'll talk about important in a little bit but this to me isn't something that should generally come up too often and if I really needed one of them to be different I'd probably have a different way of distinguishing it but yeah just to say for me I don't have any issues with this uh one of the reasons you'll hear use a single class selector everywhere is also when you're on larger teams and there's lots of people that are in the CSS and writing CSS it just prevents people from doing something like a ul lia and then what this is doing is boosting the specificity of it for no reason whatsoever um or I guess that's this one would be here the ul lia right so there's no real reason to do that it's not going to cause any problems most of the time but I don't feel like it's actually accomplishing much either and it's just faster to write this I know some people who really do still want to be explicit with it and in some situations you do want to be explicit in the way you're nailing down within your selectors but if you can get away with it I do like the idea of keeping the specificity lower but I think scoping our styles like this there's nothing wrong with it at all in my opinion now the other one that I've mentioned this a couple of times now uh off the start was dealing with m's and let's say we have my title here CSS best practices are they really for the best um and what we could do is I could come in here and I could put a span here and wrap this all in a span and so I have my h1 and then the spanning guess what on an h1 you don't really need to have a class on that because you should only have one h1 on every page too um but we could have either I I tend to have a site title class just because I'm so used to doing that but having an h1 that is your site title like it's sort of what it should be but that can change depending on layouts uh and the one thing in a way I do like separating style from the look of a heading just so we don't use headings in the wrong way because they're very intentional on how we should be using them if you'd like more information on that there should be a card popping up somewhere up there right now um but so actually we'll come in and we'll give it that site title because I actually have a class for that uh site title and so let's go look at our CSS and let's go find that site title class and it's right here and it's using a clamp to set the font size and if you're not familiar with clamp it just uh it means that I'm using viewport units in the middle so it can grow and shrink but the clamp will stop it from growing more or shrinking more uh but you know we have this growth factor in the middle and then I have my maximum font size and my minimum font size right there and one of the advantages with using m's here is let's say I did my site title and then we choose just like I said before I do this all the time site title and then choose the span inside and I could set the font size and then I could try and come up with another clamp to muck around with that or I could just say it's gonna be 8.6 m and let's also do a well just do an opacity to lighten it up opacity of 0.7 maybe uh and I guess the line height line height of one um would actually that's impacting this one as well so that's not I won't worry too much about the line height but you can see that the font sizes this is smaller and it's 60 percent basically of of what this one is but that means as that big one is shrinking and growing the other one is shrinking and growing with it because this is set in m so the font size of the span is completely reliant on the site title itself and of course you could go the other way with this as well where you know if you need something to be bigger and you're setting a set font size and then you're purposely saying this other font size should be either bigger or smaller and it's always going to be in relation to that base font size that you have and this is one of those things where I would not use m for all my font sizes it's just one of those things that you just need one misplaced font size declaration somewhere and it can muck up a whole bunch of stuff so it can get a little bit dangerous but when you use it intentionally you use it for a specific purpose to accomplish that compounding thing that could get in your way then it's actually a really smart way to do something and it makes your life a million times easier so I think we'll bring this one back down because it's a little bit big and we can stick with it um on something like that now as we're going through this I have a couple more that I want to talk about but first I just want to say like for yourself to be able to make these decisions if you've been writing CSS for a little while now and you're sort of comfortable with what you're doing you know you're not an expert that's completely fine but you're sort of getting a little bit more into the swing of things and actually recommend that you rewind a little bit and you go back to the basics and some of the early things that you learned because when we first are learning it we're learning the syntax in the box model and all the different properties and all the different values and the units and there's just there's so much information overload which is one of the reasons that we get all of these trade things that are basically training wheels to sort of help us out so we don't have to worry about everything and then what you can do is later on go back over those fundamentals and see like oh man I talked about the box model I got a rough idea of what it is but I sort of understood what it was but it wasn't the focus of what you're doing there you just sort of got okay I can set wits and padding on stuff and then by rewinding and going back over some of these things again it can actually start making other things that you've learned along the way make a lot more sense and I always recommend people sort of stop at one point and go backwards because it actually can help you go forwards a lot more you know it's the one step back three steps forward type of thing and if you'd like a bit of a learning path to be able to do that sort of thing I have a course called CSS demystified where the first part of the course is all about that idea of revisiting fundamentals you already know about and then the second part is going over what I like to call the unknown fundamentals like formatting contexts and containing blocks and some of the other things that often don't you don't hear enough about and this course is really for people who've been writing CSS for a little while now they're sort of past that beginner stage going into the intermediate stage or they are intermediate but they're not really confident in using CSS and they're trying to get gain that confidence and they're just struggling to make that next step with it if it sounds interesting to you the link to the course is in the description below and now I guess we keep on going and the next one that I actually want to talk about is the idea of mobile first and how I don't think you should always be going mobile first it's a really good best practice I think it's a good general rule of thumb in a way but I do think there's times where you want to avoid it and one example is this space tourism site that I built out that has this navigation here and if we open up my dev tools and we'll go into responsive mode just so we can see if I make this smaller and just if the responsive mode is this little icon here firefox has one too it's there in your dev tools so if you want to get it it's not people always ask me about it but you can see the navigation changes here and then it jumps over to this mobile navigation here where we get like the slide out with the hamburger menu when I created this in my video on it again it's linked I'll link it in the description but there was a commenter that got really upset that I did use a max width media query here and you can actually see that this one here is a max width and here I have a minute of max and then I think these are just the max widths maybe um but this one is a max width media query um which and yeah here's like one of those ranged ones and this is something I don't tend to do very often but in this case it made sense to me and the reason I did that is just because the navigation at this stage is pretty simple we throw a display flex at it the items sort of go where they want now I'm setting up like as much base styling as I can here so I'm setting up like my primary navigation I have a gap that I can use I have my list style none my padding margin all of these things can just be applied to it because these are going to be universal across every single font size but if we come and take a look inside my max width media query here I have a lot of different things that are being added here I have a position fixed with a z index because it's positioning I have an inset which is your top bottom left and right um I have my padding I'm changing the margin I have a flex direction on there there's the transform because it needs to slide in and out and there's a lot of styles for hamburger menus in particular often that we're adding we have to have an open state in a closed state and all these different things there's a lot of extra complexity at the smaller screen size that we don't have at a large screen size for a navigation and so for me the idea is less so let's do things mobile first and instead it's take the path of least resistance and of course that's just setting all of this up then I also have that toggle that I have to deal with and I have to you know do I have to style a toggle to be in there that I don't actually want to be visible so like why should I have all of these styles set somewhere that then I have to remove somewhere else if I can just put them in a max width media query right there's all this stuff that's coming in there and maybe then I have a few other things and here's a min width media query most of the stuff I do will be in a min width media query or no media query at all because I want to do as much styling as I can that's just universal across every screen size and then I'm going where am I adding complexity if I'm adding complexity at larger screen sizes which is tends to be what happens your layouts tend to get a lot more complex so like if we come and take a look at this let me get her to the way when we're looking at this like or let's go look at the destination page whereas like if we take a look at small screen sizes here they tend to be a lot simpler right where everything just stacks on top of each other so as far as the layout goes there's not a lot of complexity here so I can style all of this up without any media queries I just style it up it's all just stacked set my font sizes set everything up and then I worry about the layout getting more complex oh look here we have to go to two columns so we're adding complexity in in a media query then over here we can add more complexity we're getting this is going to two columns now and the layout's changing a little bit more adding complexity and as the screen gets bigger which is normal so all of those go into a min width media query whereas the navigation there's a lot more complexity at the smaller screen sizes so you might as well throw that in at a max width and in a navigation is the common one that I always talk about but I guarantee you there's other situations and other things along the way to where there's like this element is so much simpler on larger screens and much more complicated on small ones you might as well put it into a max width one so when you do get to those larger screen sizes you're not using a media query to try and overwrite a whole bunch of CSS you've already done and that leads me to the last one that I want to talk about which is we can go back to this original one that we were looking at and I sort of mentioned it with that purple example actually of using important and if you want to use that I think if you have utility classes that you just want them to work all the time maybe you could come up with a good reason to use important I doubt it though it's not true I do think you can get away with using important if you're using it in a very specific way and again utility classes tend to be that one area where you just want that utility if I'm doing a dot you know I'm saying that my color is purple I want the color to be purple and I want it to be important I want it to be purple no matter what and the advantage of with that being on import you can see I don't use it much I can't spell it but the the reason this might be okay is because it's a single class meaning if I needed to change it I could just remove that one class and the only impact it's going to have is that one thing that it's doing so if it is on a utility class it's probably not the end of the world whereas if you're mixing it in like say I did this instead of doing it there I did that on my primary navigation right here on the links and I had the color coming in as purple and then we have the text decoration and then I have a font size of 0.75 ram or whatever we're making it super we'll do I will make them really big not really small whatever I'm coming in with a whole bunch of styles on something and I have an important mixed in there that's where things get dangerous because then how do you overwrite that because you don't want to remove all that other stuff but you have this guy floating in on there so I tend not to use important on anything I generally the only times I see important used is when people have gotten into trouble with using an id selector somewhere or going kind of crazy with other stuff and where they haven't thought of the implications of it when they were creating some weird selectors and then they have to come in with this or you're using like a page builder that's doing something and then you have custom css coming in on top of it stuff like that it's good to know how important works so when you're stuck in a situation where you have to use it you're able to get away with it I would generally say try to avoid it because even with utility classes you probably don't need them in the first place you can even have like layers and cool stuff now that we can do that I'm not going to worry too much about right now but you can actually just make sure your utility classes are always going to win so in general probably don't use important but know how it works just so you can use it if you have to use it because I guarantee you you'll write you'll get a legacy project somewhere along the way where you have to update something you might not have a choice so knowing how it works is a good thing and there might be one or two situations that you could actually set something up where it's not a terrible idea but you probably don't need it so maybe just don't use it would be my general advice on that front and I'd like to know what you think of any of these ones I've said am I completely wrong let me know in the comments do you have other ones I didn't mention that you think are completely fine that people are always saying don't do this leave that in the comments down below as well I'd like to know all of your opinions on this so please leave a comments down below and let me know what you think about all of these things and tell me about all the problems you've run into in projects where you came across where there was important being used and it just screwed you up completely I'd love to hear about it and I think the one thing that this does boil down to and sort of the the wrap up of this idea because there's many others I could talk about but it's that there's many ways to skin a cat but just don't feel like you have to adhere to very strict ways of working but do know why people suggest it so if they say always use class selectors everywhere a single class selector everywhere why why do you think that's a good idea and if you start running into problems where you're using descendant selectors like I'm doing here you'll start quickly going oh I guess I should and even this one you know maybe even if it's like this and then you end up with that second nav so you're going oh I'll do a class now so I can be more specific on what I'm doing and then eventually maybe you run into an issue with that even whatever it is but by understanding why those rules exist that's when you're allowed to start breaking them because you probably have a good reason to actually break it and it makes sense in the situation that you're in and it's also the fun of CSS where there's lots of different ways to accomplish the same thing sometimes another example of that and it's I guess a bit of a joke or meme these days is centering with CSS which has gotten a lot easier because we have flexbox and grid to center things now but sometimes we're not in a situation where we can use flexbox or grid because we have a position absolute or fixed or whatever it is so if you'd like to see five different ways we can center things without flexbox or grid and some of them are really bad ideas and some of them I think are actually pretty good ideas you can check that video out where I look at those right here and with that I would like to thank my enablers of awesome TTLLD Andrew James Michael Simon Tim and Johnny as well as all my other patrons for their monthly support and of course until next time don't forget to make your corner the internet just a little bit more awesome