All right, I think I'm gonna get started. Can you guys hear me all right? Is this too loud, too quiet? Good, all right, cool. So thank you guys very much for coming to the session. This is my first time at a DrupalCon and also first time in LA and I'm having a blast so far, so good stuff. So I realize that there are some code examples in here and if you guys are having trouble seeing, especially the folks in the back, I have a link up here. It's dc15.jacranus.com, j-a-k-e-r-a-i-n-i-s if you want to follow along. So, quick show of hands. Who here is a back end developer? All right, cool. What about a front end developer? All right, cool. And then who here is not a developer? All right, a couple guys, cool. Everyone's welcome. So we're gonna be talking about a number of cool techniques. It's a little bit more technical, a little bit more of a technical focus but I think it will give everyone a good insight as to some of the struggles and the decisions that we need to be making when we architect large scale Drupal sites. So just quick introduction. My name is Jake Rainis. I'm from Boston, Massachusetts. That's my cat, Beretta. She's a hairless sphinx. And I've been coding since I was in sixth grade. I started dabbling in HTML back when I was bored in my social studies class and I built websites and Angel Fire and GeoCities. If you guys remember those. So yeah, good times, right? So those sure were the days. But fast forward. Currently a senior UI developer and a team manager at Genuine Interactive. We are a full service digital agency digital agency based out of Boston. But we have offices all across the country. We work in all sorts of platforms but of course one of our favorite to work in is Drupal. So through a lot of trial and error we've learned a lot about what it means to write good code for Drupal and some of the struggles that we go through on the front end and that's gonna be largely what I'm talking about today. And as a result it also helps us work harmoniously with the backend which is always important. So I think we all know that the secret to good web development is to write code that doesn't suck but how do we actually do that? Today we're gonna focus on three goals that allow us to do that. The first is gonna be to figure out how we're gonna write our code logically in an organized way that allows us to scale and have portable code. We're gonna wanna figure out how to write our code semantically so it's understandable to our fellow team members as well as ourselves down the line when we need to revisit these sites and figure out what the heck we were doing when we were working on it. And then also we want our code to be dry which is an acronym for don't repeat yourself. We wanna write our code once and we wanna do it efficiently. We want it to be bloat free. So what we'll actually cover before we get into good practices we'll talk about the importance of abstraction, talk about the philosophy of why it's important to break up our code for reuse. And then we'll talk about CSS patterns which will allow us to architect our code in an organized way. We'll explore block element modifier syntax or BEM syntax as some of you guys might know it which is a way to write semantic classes. And then we'll also get into SAS a little bit. And even if you're not super familiar with SAS or if you use less or something this will be a good jump off. So before we get into all the good practices let's talk about life without them really quickly. So let's pretend we're kicking off a massive project and we have that common criteria that we all know and love. So we have an aggressive timeline and a tight budget. We have set very high client expectations and our client's happiness is very important to us in our business so we're gonna need to figure out how to please them. And then there are also a lot of unique templates. Our designs are very high fidelity. Our design team has taken great care to create this experience that we're gonna need to bring to life. And so likewise we're gonna need to take a step back and figure out how we're gonna bring this code to life and do those codes or do those designs justice. And then as usual the team is gonna have various degrees of experience. I will have some developers who are gonna know how to take direction and we'll have some, or they're gonna, you know, they'll need a little bit more direction. We'll also have developers who are going to know how to take the reins. But regardless we're gonna need to figure out how to have our team work effectively together. And the last piece of criteria it's also responsive but I didn't need to tell you that cause all sites are nowadays. So given the current scenario, one of the first problems you might run into if you don't have a plan in place is where do you actually start? I know for our team a lot of our projects start with static templates. So I'm gonna be writing markup. I may say, all right, I'm gonna start on the homepage, you start on the inner page or I'm gonna work on this component, you work on that component. But unfortunately forcing this approach just doesn't work. We're dividing and conquering but dividing and conquering isn't quite enough. And if you divide and conquer without a solid plan in place you're already gonna set yourself up for a big headache. I love that give. So without a plan, team members straight from the get go you're gonna be dividing their responsibilities. They're gonna be working in their own isolated bubble and this is never good, right? Because when they're isolated there's no real sense of organization. If you're not using a partial, if you're not breaking out your code into different files, if you're working in one style sheet you're gonna be screwed. So you should never do that. But developers are gonna be building a piece from top to bottom. So I may be working on one layout, someone's working on another layout. There's gonna be one piece that I'm building that perhaps that other developer could use or vice versa and we're not gonna know about that because we're working separately. We'll be forced to come up with our own naming conventions, our own organizational patterns and it will just quickly become a mess. Worst part, no concept of a bigger picture. The code and the code's authors are isolated. So that's not to say that we can't get to launch that way. We can build a website this way. It has been done. I know that I've done it in the past. You gotta start somewhere. But when you get to launch, unfortunately, that's just not really the end of the project. We all think of it as the end of a project, but it's really just the very first milestone. So websites never really go away. We're stuck with what we wrote. And I'll be surprised if any developer in here doesn't have at least one of those websites that you're stuck with years down the line performing the monotonous maintenance tasks and whatnot. I know we have a lot of those. I think every big company does. And one of the problems that comes up here is when you have a big team and you have new developers coming on, you have new websites launching, you're gonna need, or rather, what is the likelihood that the same developer that built that website is going to be working on that website for its entire life cycle? For us, that's never the case. Our team grows, the amount of websites we do grow. And then the websites that we launch eventually go into a maintenance retainer of sort. So we're gonna need to bring a new developer on at some point. And when a new developer comes on, this is where things get worse, because here's what happens. We have the developer set up and explore the file structure. They have to try to figure things out, figure out what's going on, and this takes time. And unfortunately, time is money. And then once they get the project set up, they're gonna realize that there's no real system or plan in place. So they're gonna start to do it their own way. And as more developers come onto this project and go off of this project, there's gonna be this really clear lack of ownership and responsibility. And that's unfortunate, but it's the reality of things, because when someone is gonna come on to a project for maintenance, they're gonna say, all right, I wanna get in and out of this as quickly as possible. I have a lot to do today, and this is not my project. I'm not responsible for this code. I'm just responsible for this one little piece, this task that I'm gonna do today. And then as new fixes or features get added on, old stuff breaks, it's like a Jenga Tower, spaghetti code, things are strung together, and it really just becomes a mess, and it's no fun for anyone to work on. So at this point of the presentation, I wanted to kind of shift the mood and bring up something a little bit more positive, so I figured this be a good place to drop a quote in, something motivational or maybe a little stereotypical philosophical quote about setting goals. I got on Google and I found this one by this guy named Charles DeLint, who is actually just a Canadian young adult fantasy fiction writer, not super applicable to web development, but it resonated with me. So the role leading to a goal does not separate you from the destination, it is essentially just a part of it. And if you think about that in the context of web development, it actually really is applicable to what we do. Because when we set out to develop something, we generally have an end goal in mind, and this end goal is usually launch. We dream of it being awesome, we think of all the hard things that we need to do to get there, we work hard to get there, and then we can rejoice in our victory, right? But if that hard work isn't good, then we don't actually achieve our goal. We've been short-sighted, we haven't actually thought about what is gonna happen with that website after it launches. So if we're not actually traveling that road to Charles DeLint's destination the right way, then we're actually failing. So we need to figure out how to do it the right way. And that brings us to our first goal. So our code must be logically organized in a way that allows us to scale and reuse. But how do we actually write this code to reuse? So what is reuse? I've said it like 50 times now. What does it mean in web development? To me, it means finding common patterns and reusing them. So I chose the media object as a really prime example of this. And if you guys haven't heard of the media object or are not sure what it is, I promise you that you actually do know what it is.    It's essentially just a generic reuse content item. It generally consists of an image with corresponding content. You'll find it in one or two columns.  So post. This is my post. This is a media object that is gonna appear on your timeline. It's gonna have an image with corresponding text, which in itself actually is a media object. Below that, I have my friends commenting. Those little comment blocks are media objects. They have an image with corresponding text. Below that, I can leave a comment. You can leave a comment. And it's an image with a corresponding action. Top left, that's my picture with a corresponding text. And then if you actually look at a timeline advertisement, this is completely different content. It's being brought to you for a different reason, but it's essentially the exact same markup. It's in an image with corresponding text. It's slightly different, but it's essentially just the same markup being reused. And then on the right side of the timeline where you have all those irrelevant ads from the thing you looked at once on Amazon, this is the ab roller that I looked at once when I went to grab this screenshot to work on my beach body. But again, this is just corresponding text with an image, right? So it's really everywhere. It's certainly not something that's specific to Facebook. And in the Drupal sites that we build, we often find these media objects in views or these blocks that house resource content, or resource content, blog posts, just archives content. And these different media blocks throughout a website can house unique content and they can have different aesthetic treatments, but the HTML can be the same. And if we abstract them to allow for all those different contexts, then we can essentially just write something once and reuse it everywhere, which is a lot more efficient. So that's reusability, but how do we actually architect this code so that we're not just dumping in one place? How are we gonna do it in a way that's still accounting for all the different aesthetic treatments and the variations and the themes? And then how are we also gonna do it in a way that makes sense to our team members? We're gonna use a robust pattern-based system. So in the past five years, there's been a lot of innovation as to how to write CSS for large-scale websites. You might have heard of Nicole Sullivan's Object Oriented CSS or Jonathan Snook's SMACS, just Scalable Modular Architecture for CSS. These are both great methodologies. Today I'm gonna be talking about atomic design and a little bit more depth, but it's certainly not because that it's better than these. These are essentially just the, they're just different ways of getting to the same goal. And so if this is something you're not familiar with then I would definitely recommend checking these methodologies out. But getting into atomic design, which is a system for designing pieces and not pages, we'll talk about a little bit more what that means. But I just wanna talk about the creator real fast. Who here knows who Brad Frost is? All right, cool, good amount. So for those who don't know, real quick, he's a really forward-thinking thought leader in the front-end community. He's contributed tons of rich content. He's currently hosting or presenting that is at an event apart in Boston, back in my hometown right now. But he's influenced, oh no. Sorry about that. I think it's coming back. Ah, sorry guys, I must have hit something. Lost my notes too. Ultimate fail. I'm gonna try not to touch my computer anymore. Searching for inspiration and parallels. I kept coming back to chemistry, the thought that all matter, whether solid, liquid, gas, simple, complex, et cetera, is comprised of atoms, and those atomic units bond together to form molecules, which in turn combine into more complex organisms to ultimately create all the matter in our universe, which is pretty deep. And so this explains the name and outlines some of the patterns that you'd be using in atomic design. Your styles would be broken down into these five parts which you would theoretically organize methodically into SAS partials. So starting from the ground up, these are the very smallest bits, these are atoms, and these are the smallest building blocks that are gonna make up your website. So by themselves, they're not gonna have much context. They're gonna be sprinkled throughout, and they shouldn't have much context because they should be agnostic to their parent components. They're likely gonna, they're gonna comprise of things like the things listed here, not limited to that certainly. But so we have this page design that one of our awesome clients let us use for this demonstration. And we take a look at this design and we say, all right, how are we gonna actually break this apart if we're gonna do it atomically? So the key here is bits. Again, these are the smallest things. We're breaking things down into smaller pieces. We're isolating typography in single elements that can be reused elsewhere regardless of their context.  In taking our inner page design, we see a lot of those same bits being reused. So if that context is always gonna change, then we'll wanna code them once and reuse them globally so that they're portable. And then it's also important to write our code in a way that's gonna be agnostic to its parent context or container. And that's really just the key to abstraction. So those are atoms. If you climb up to the next building block, our atoms would form together to form a molecule. And again, a standalone atom by itself isn't super useful, but when you put them together, you actually see how nicely this approach works. So you can take your inputs, your labels, and your buttons and create forms with them. You can put your nav links together, unite it to create a navigation system. So here, we separated those forms, labels, and text input in the top right corner. And now we're able to unite them together into like a global site search that lives in our header. So again, these little pieces are becoming something a little bit more tangible. And then our other inner page example, we have a sub navigation link style. And these navigation link styles can have like an inactive, a hover state, an active state, but we can add context by positioning them together and giving them a background color. And so then again, our atoms will unite to create another example of this different media object. So by now, you're probably starting to see the kind of bigger picture here. An atomic design, we're just putting our smaller building blocks together. So our atoms and molecules will join together to form organisms. And these are gonna represent the bigger regions of your page. So going back to our design, this is where we were with molecules. We're gonna form organisms. We've merged together our molecules into a header and a content organism. And then with our inner page design, we're also doing the same. We have a header, we have a sub nav, we have our content section. So it's worth noting that once you get to this point, you've really actually broken things down enough to be portable and reusable everywhere. So as you probably could have guessed, the groups of organisms will come together to form templates. And templates are the structural layout of your page. You're not actually gonna be writing a ton of code here. This is probably where you'd put something like your grid system or just the styles that are gonna position these regions together to form your actual page design. So then the last piece, pages, which are really similar to templates, but not to be confused, they're meant to be variations of these layouts. So what would your website look like if you were logged in versus logged out? Is your header gonna have different components in it if you're logged in? What does a site search look like if it has 10 pages of results in warrants pagination? What does it look like if it has just two results and doesn't warrant any pagination? And what does it look like if it doesn't have any results at all? So it's worth mocking up these variances to account for unexpected behavior. A lot of times our design team is not gonna think of these more unique scenarios. And sometimes we don't think about them in development either until it really becomes a problem. So it's definitely just worth thinking about these things as early on as possible. And it's also worth noting at this point pattern lab, patternlab.io is the website, which is created by Brad Frost again, who is the creator of atomic design and also a developer named Dave Olson. And patternlab is not meant to be confused as a framework. It's a set of tools that are meant to help you construct your website in an atomic manner. So I actually put together a screencast today because I was not sure if I'd have wifi in here. And this is just a screencast of me clicking through a demo of patternlab. So along the top left navigation, you have your little pieces starting with atoms and working your way up the chain. You can look at these elements just by themselves. You can look at an individual button. You can look at something that has a button in it once it becomes a molecule. And this makes a really, really great living style guide. We've done this for clients before and they really enjoy it. It's kind of a newer tool, but it really helps us think. So again, pages, this is our regular homepage. This is what it would look like with an emergency alert on it. So again, accounting for those variations. It's responsible. It has a small, medium, and large setting. You can also set an explicit setting. And it also has a disco mode, which in real time will make your page dance for you. So you can actually see a breakdown in real time. And you know once you start, especially I'm sure front-end developers can relate, once you actually start making responsive sites, every responsive site you go to, you want to check to see if it's responsive. So if atomic design is something that you're excited about, then I would definitely check out Pattern Lab. Very cool tool. So I really like atomic design. I think it's really cool. I hope you guys have a good understanding of it too. What's nice is that it really encourages good organization that helps with our scalability goal here. And it doesn't impose strict guidelines. It encourages good practices, but you don't actually need to follow these guidelines if you don't want to. At Genuine, we don't like to impose too many guidelines either, but at the same time, again, we have these developers, this big team of developers with different projects. These developers are coming on and off these projects. And so there needs to be some degree of standard so that we're not wasting a lot of time learning how each other code. So atomic design was a really good step in this direction for us, but when we introduced it to the team, a lot of questions came up. Things like, where should I define my variables? Where should I put my mix-ins? Or let's say I want to use a third-party script plugin for a carousel. Where do I put this vendor CSS if it comes with one? And then a question we all asked a lot, including probably mostly myself, is this a molecule or an atom, or is this a nucleus? But the problem is that there is no nucleus in atomic design. The scientific terminology wasn't super intuitive. And though I appreciate the terminology, I was never super fond of the metaphor. I didn't really do that great in chemistry. And so I always found myself double-checking. So it was these frequently asked questions that kind of led us to evolve the way we were using atomic at Genuine. So this is a quick peek into what our common project style structure might look like. So we have our screen.css, which is compiled from screen.scss.  And then we have these six folders, which you'll notice are numbered from the very smallest building blocks to the biggest. And you'll also notice that we've done away with the scientific terminology. So our atoms become pieces, molecules become components, and organisms become regions. And then finally you'll also notice that we have these two extra folders, utility and core. And so what these are to us. Utility is where we keep what we call the intangible bits. This is where we would put that, the mix and code or our font declarations, our variables, if we have vendor.css, we'd put that here too. And this is code that you're gonna use, but we call it intangible just because it's there, it's in the background, but you're not spending a lot of time interacting with it. You're just using what it's providing you. And then with core, this is where we keep our raw HTML styles. So if you were to strip all of the classes out of your website, what would it look like? How is the typography treated? We would generally break these aparts into partials as we see fit. Things like forms, lists and tables, will generally warrant their own partial. But there's no rules here. It's just really to style that raw HTML, because we find that if we can get that stuff out of the way early on, we spend less time accounting for different variations down the line. So yeah, that's how we do it. I really love how easy and intuitive it is. It counts for all the different situations that we've been in. It works well for our team. Atomic design may not work well for your team. Perhaps another system does. But the most important thing to keep in mind is that it's not the end-all answer. There's a lot of different ways to do this, to do organization, to scale your website. The most important part is that you just have a system that is gonna work for you. So if you have a system that works for you, then we've accomplished our first goal, which is to organize our code in a way that allows us to scale and reuse. So let's move on to our second goal here and explore how we can use BEM syntax to write code for an unfamiliar developer. So again, BEM syntax, BEM is a acronym for block element modifier. It was created by yandex.com, which is a Russian search engine company. And it's essentially just a method of writing classes that are semantic that makes sense. So this is what those classes would look like. We have a block, and our block is essentially just gonna encapsulate children, child elements. We have an element, which is divided from our block with two underscores. And then we have a modifier, which is divided from a block or an element with two dashes. So by itself here, that doesn't make a whole lot of sense. Let's take a look at a real world example. So here we have a login form. This is just a common login form. Our login class on the form element is our block. We have child elements, we have two labels, two inputs, and a submit button. And when we look at this, we can see that, all right, this class has two underscores in it. So we know that label and input are our child elements of this login block. We can also add a modifier, and we do on line six, where we have login input error. And so let's say we have a gray border around our login inputs, but then we have this front end validation that happens to catch when a user forgets to enter their password and appends this login input error class, and then makes our input have a red border. So we know when we look at this exactly what's going on, we can see that we have an input that's in an error state, we know that it's in an error state because there's two dashes, and then we also know that it belongs to the login block because there's two underscores. You can also modify a block, it doesn't have to be just on an element. So here we've put the entire form into an error state instead of just the input. So we have login error, or login dash dash error on the first page. I'm sorry, first line. So it looks a little bit weird at first, and when I've talked about this methodology with people, the first question they always ask is what's up with all the underscores and dashes? And it definitely, it looks like it kind of convolutes your code, but it really does serve a semantic purpose. First being that there are lots of classes out there that have single dashes and single underscores in them. So we know when we're looking at one with a double underscore, a double dash, that it's a BEM syntax. And we also can see exactly what is going on. That's really the beauty of this. So we can see what state something's in, what it's doing, what it belongs to, what it is. And so I think you'll get used to it. If you really give it a shot, I really hated it at first. I recall using the word DOM vomit when I first saw BEM syntax code. It looked convoluted, but now I kind of see it as something that's really organized. And when you go back from working in BEM syntax to something with a lot of arbitrary classes, you'll definitely appreciate what BEM syntax does for you. So yeah, quick and easy, that's BEM syntax in a nutshell. It's really just a useful convention to write classes that make sense. We've also been using it a lot at Genuine. It's really helped unite our developers to have a standard amongst our projects. So quick show of hands again, who here uses SAS? All right, cool, a good bunch of people. Who here doesn't use SAS? All right, cool, that's fine too. So the ins and outs of SAS are a little bit beyond the scope of this presentation, but it will also serve as a good jump off. For those that don't know what SAS is, it's a CSS preprocessor. And what that means is it's essentially just a way of writing CSS in a slightly different syntax that is gonna compile down to CSS. And while I do that, it's a shorthand. It allows us to write less code. And it also affords us some dynamic leverage, which we'll get into. If you don't use SAS, it's never too late to start. You should definitely give it a shot. It's really awesome. So in the interest of our third goal, which is writing our dry code in an efficient manner, we're gonna talk about the BEM syntax capabilities that SAS actually gives us right out of the box. And then we're gonna talk about how powerful it is, which will involve a lot of the good that it can do, but also some of the pitfalls that you can get into if you're not using SAS in a responsible way. So SAS has built-in BEM support. You don't need SAS to write BEM syntax, but it really makes it easier. If you're doing it in plain CSS, it's gonna require a lot more writing. So the way you write BEM in SAS is by nesting. And we're gonna talk about nesting a little bit more in a minute as a means to define scope. But here we're nesting these selectors in a way that's not gonna create a chaining bloat, which we'll also talk about. Our rule here says our login underscore underscore input class has a border of gray. And then also that ampersand is gonna append the dash dash error. So if we have login input error, it's gonna get a red border. Now that's a little bit different than if we were to do it without BEM syntax. So here we have a rule that is essentially achieving the same goal, but we're actually writing more SAS and it's actually giving us a little bit more output. Because what we're doing is we're saying if we have the login input class, make it gray. If we have a login input that has a child, I'm sorry, it has a sibling class of login input error, then give it a red border. So you'll see down below, we have login input dot login input error. I'm gonna flash back real quick to the previous screen and you'll see that that class is actually shorter. Not a huge deal in this context. We're only really saving a couple of characters, but if you're writing a really large scale website and you have thousands of these all over the place, then you're gonna end up with a much longer style sheet than you need. So one of the best parts of SAS is this ability to nest declarations as a means to define scope, but it's also one of the most dangerous. And if you don't do it carefully, then you can get an exponential output. Your code can multiply in a very unfavorable way. And if you've ever heard the word selector inception, that's what that means. So for example, here's some HTML, pretty standard block of HTML. We have this wrapper, we have some other HTML that's not pictured here. We have this sidebar region that has a user block and then it has our login form from a previous example. Now with SAS, we have the ability to nest to our heart's content, but just because we can, doesn't mean we should. So here we have this nesting that's five layers deep and someone who didn't know any better may say, oh well I'll just have this mirror my HTML and then that way it'll be really easy for the developer who works on this project next to know what's going on. Which may be true in some cases, but it's actually not. If you have a really long style sheet with a bunch of nesting, it's really hard to figure out where you are. But to drive the point home when you actually do that nesting and you compile, this is what it looks like. It starts to look like a pyramid. So with all the nesting, look at how insanely long some of these selectors get and that's not good because we don't need to do that. So it's important to note that SAS efficiency isn't necessarily about how many declarations you have or how long the declarations are. It's just about avoiding exponential output, but exponential output can result in these long declarations. So the key is to check what you compile. I found this absurd block of code in a vendor plugin somewhere. And I thought it was ridiculous. I was going through my compile CSS and I was like, geez, I can accomplish this with one line.  No one wants to do that. But the thing is when you're working with a preprocessor, you're never actually working in your compiled code because you're writing code that gets compiled. So it's really important to know your compiler. Go through that code and see if there's any of those inefficiencies in there that you can strip down and simplify because if you're being repetitive, there's always a better way of doing something. So keep that CSS as small as possible. And it's also worth noting that SAS doesn't create bad code. A bad coder does. So it's not a solution to your bad CSS practices. It's really just a powerful tool. It can be a really dangerous tool. And I'm gonna talk about, I did talk about, I'm gonna continue to talk about some of the bad things that SAS can do, but I'm not bad-mouthing SAS. SAS is an incredibly powerful language and it's just really important that you know how to use it the right way. So let's take a look at another way we can kind of use it more efficiently at extends.  So here we have this generic error class. We have a login input error class and we're saying we wanna use those exact same styles. What the at extend directive does is it tells our preprocessor to lump this code together into one declaration with a comma delineated list and then outputs those styles once. So another example, let's take a look at a media object. We have this media block. It has a nested H2, a nested paragraph. And then we're having this media alternative class at extend it. Maybe that class is gonna get its own style somewhere down the line. But you know, just another common situation. So when that compiles, as we expect, we get these, we get three blocks. Our preprocessor knows that it's gonna chain these two selectors together and give it the applicable styles. But let's assume that we may have other siblings next to these media objects. Let's say they're stacked on top of each other. And so we add this rule, it's a sibling rule, and it says, all right, for every media object that is next to a media object, give that subsequent media object a margin top of 20 pixels. So again, a pretty common situation. We're just adding margin to let things breathe a little bit. But when we compile that, look what happens.  So again, no one ever would have thought that to, no one ever would have done that on purpose. But it's just, it's important to think about when you're mixing at extends and sibling selectors, things can get messy in an unexpected way. And then there's also the confusion of when to use mix-ins versus when you're using placeholders. You could achieve essentially the same thing with both a mix-in and a placeholder, but they actually are very different beasts. So when you're using a mix-in, you're not using at extend. You're using the at and clue directive. And when you use the at and clue directive, you're explicitly duplicating something. You're copying and pasting something. Whereas when you're using a placeholder, you're gonna be using the at extend, which we took a look at is the preprocessor knows that it's gonna create a new declaration from these styles. So let's take a look at an actual example. So here we have a mix-in. We get a lot of designs that will have gradients. And so the developer may think, all right, I'm just gonna create a mix-in so I don't have to write all this background gradient code over and over again. So they create this background gradient mix-in and then they're gonna apply it to styles with the at include background gradient. Now, when this compiles, we get the expected output. Everything works, but you'll notice that this code is just copied and pasted. And so we're repeating ourselves and we don't wanna do that. So we know that there's probably a better way to do this. And that's where a placeholder comes in. So here is the same example that we're trying to accomplish here. We have a background gradient. The syntax is a little bit different. It's prefixed with a percent sign and that tells our preprocessor that this is indeed a placeholder. And then instead of saying at include our mix-in, we're saying at extend percent background gradient, which is extending our placeholder mix-in. And then when this outputs, again our preprocessor knows to take these common styles, create a new block, a new declaration that is gonna chain our selectors together and give them all the same styles. And then it will also leave the unique styles on those classes alone to have their own individual classes. So cool. We've achieved half the output using a placeholder. We know that at includes duplicate and at extends will create this one new rule. So why use a mix-in at all? And the answer to that is because mix-ins can have a dynamic output and this is explicitly what you should use mix-ins for. So we had this background gradient and it was the same background gradient that we were gonna be using all over the place. So we should have used a placeholder. That was the way to do it. But what if we wanted our gradient to have a different output? Say we had a design that had different color gradients that were going in different directions. That's where a mix-in would come in handy. So going back to one more example, this is what a mix-in gradient that had a dynamic quality to it would look like.  So it takes arguments. So we have color one, which is what our gradient is gonna start at. We have color two, which is the color that our gradient is gonna grade eight to. And then we have this optional direction as a third argument. We know it's optional because it has a colon prefixed with top. So we know that if we don't pass in a third argument, then it's just gonna default to top. So when we call it below, we're saying at include gradient and then we can pass it, I'm passing it explicit colors here, but you can pass it a hex value too. So this is gonna create a white to red gradient and it's gonna take the direction of top. And then another element is gonna take a completely different set of arguments. And so when we compile our code, we're seeing that we're actually getting this completely different output. Again, that at include is copying and pasting code, but it's not copying and pasting the same code. We're getting completely unique output. So that's what mixins are for. And the rule of thumb is that these mixins should accept dynamic values and they should return a dynamic output based on those arguments that you pass to it. But if you just need to reuse this same code over and over again, then you should use a placeholder. So this was a tough thing for me to grasp initially. Learning CSS itself isn't a super hard thing to do. Learning how to write CSS that is a little bit more large scale and organizing it, that can get difficult. But then when you throw in like a preprocessor that has all these different ways that you can write CSS, it really can become a headache. So just drill the difference into your head if you don't already know the difference between add extending and add including. And that will help you figure out when to use a placeholder or a mixin. And so that's just kind of scratching the surface of SAS. We don't have time to go further, but SAS can do a lot of really, really awesome things. These are some of the more powerful ones that we use on a day to day basis that I wanted to share with you guys. So we've accomplished our goals. We've explored proven systems that help encourage scalability. We won't be banging our heads on our keyboards a couple of years down the line when we need to perform maintenance on that website from hell because there will be an organized system in place. And then we've also learned how to write code that is gonna make sense to our fellow colleagues as well as ourselves down the line if we're gonna have to pick up old code that we wrote once upon a time. And then our code is no longer bloated. We know what our preprocessor is doing. We've scratched the surface of SAS and we've learned a lot about a great starting point for how we can start to architect our styles with SAS. So if you're doing these things or you're planning to do them in the future, you should definitely be really proud of yourself.  Buy yourself a beer, pat yourself on the back. And so the front end is hard. It's getting more and more complex by the day. It's been really interesting being here at Drupal talking about headless sites that was something that I had never thought I'd see but the front end's only gonna get harder. And it's important to stay up with these new things on the horizon but it's also even more important never to get too comfortable with what you're using today. But if we demonstrate this good practice, things will be easier as this complex frontier evolves because the web's never gonna be a static place but if we're responsible, then we'll be able to grow with it in a much easier way. So thank you guys. And then also I'd like to thank our awesome clients, MITRE and Interlinks who I believe are also here at DrupalCon. They let us use their websites as a demonstration today. We're very grateful for that. And yeah, thank you guys. I hope you learned something and I'll be happy to answer any questions if anyone has any. Great questions. So we figured there's so many class names, right? Why not just add more and make longer ones? No, but so with Drupal and the classes that it gives you, it's definitely difficult. There isn't a way right now to get Drupal to output classes in this way. The way that we do it in the company that I work for will often take time to strip out a lot of the unnecessary classes or we'll just work with them there. My opinion is that there shouldn't really be a machine doing this for you unless that machine is doing it really right. I think a lot of this requires some planning on the front end team. You wanna be able to do it in a way that makes sense for a large scale project and not just one little portion of a website. So we do that all manually. And then as far as analyzing the compiled code, there aren't any tools that I'm aware of. I don't think there is really the need for tools either. I think a lot of what I do is I scroll through that CSS and I just look for big blocks. Things that visually stick out to you as you're moving through that code because it's generally that's where those giant selector chains are gonna go or a really, really long set of rules. You'll be able to pick it out pretty easily. And if you use Sublime Text, Sublime Text has a little mini map. You can sometimes even see it on the mini map. Other IDEs may have that as well, so yeah. So I would say that it would probably work with our backend team to figure out a way that it was gonna allow us to add classes for wrappers on the front end that was gonna be used in one specific area instead of half-hazardly adding them to somewhere that is gonna be duplicated everywhere. A lot of our views, if a view is doing the same thing in a bunch of different places on the website and it's always looking the same, then we can use those classes. But if it's gonna look different or serve different content than chances are it's gonna have different classes. So that is generally enough for us to target what we need to do to accomplish our goal on the front end. Does that answer the question? No. So you can't assume that you can add classes to them because let's say that you don't have all the right to have that kind of access to the stuff. And so you have to use that are all, maybe they close from the top. And another view is close from the left. And so, So you're stuck with that code. Right, and so the ultimate question is what would you do with these views, see how this file is based on the file structure of the region? Because I can't tell you in a region you have components. I don't know that if it's a component, but then if it's not a component, then you have 100 views, 100 files, a lot of views. So what would you do to put that in the file structure? Gotcha, okay. So in regards to the lack of control to the markup, the BEM syntax is an ideal, or being able to add our own classes is obviously ideal. Where it can't be done, then it just can't be done.  It's a helpful pattern when you can do it. Unfortunately, in a situation like that, you may just be stuck with the markup that you have to work with. As far as where that organization would go into your code, I would say that it would probably either go somewhere between the components in the regions later, like you said, I would prefer to break things down. Like if there was gonna be, let's say we have a view with a couple different media objects in it, not all those styles are gonna live in any one of those folders. We may have typography being handled differently, like a general layout that is gonna space these things apart being handled differently. That may happen in the region section.  It really differs from design to design, and the way that we're gonna break things up is generally kind of a strategy that is gonna be subjective to every website. Versus the general, how do you approach it through the process? Like is there any tool kind of like the part of it that lets you see that the line of things is not necessarily the one that you can see is just kind of what you do yourself? So you mean like if you're inspecting the website and the browser to see how it goes back to? So there are, there's a tool that you can use with SAS or Compass, which is a mix and library built on top of SAS that allows you to use what you call source maps. And so that is a reference in this compiled CSS that references a map file that will tell your browser when you're inspecting this compiled code that when you inspect a style, that style is then mapping back to whatever partial that is responsible for defining that attribute. It takes a little bit of setup. It's probably not something you would ever do on a website that you're not working on yourself. But and then also just if you're compiling your CSS in a way that is ultra compressed into just one ugly block of code, then obviously that's not usable. But there are also other different formats in which you can compile your SAS too. So you can have one that outputs your CSS and before every line it will say this line is from this file on this line. So you're looking at this compiled CSS but that CSS has a reference back in an actual comment to where that partial is. Sure, thank you. Yeah, please do. Okay, that was a context module you said? To give it that, to get the parent, right? Cool. John, expert, help group who does this. He doesn't have to say the word on what I have. It does have a chance to raise a question.


Hi, my name is Charlie and I teach at the World Class School of Coen State High School in the beautiful Townsville region. I grew up in Tundam Sands, beautiful beach town just south of Lutston and my people, my tribe, is from the Nijantje tribe, which is in the Tablelands. It's my first year teaching. Ever since I was younger, I really wanted to be a HP teacher. My year 11 HP teacher actually really inspired me to become person I am today. Teaching is a little bit different to how I imagined it would be. I didn't think it could be as fun. The kids are great here and the experience is just phenomenal. Regular day, it's always different. I always come in, I say hello to the kids, they come to school, I make lessons engaging, I make them fun and interactive and I can always inspire them to become something that they really want to be or even something that they never thought they could be. I'm the teacher of the June Indigenous Studies curriculum at Coen Hype. Being an Indigenous teacher is really important to me. I'm able to help close the gap between Indigenous and non-Indigenous education rates and of course being that teacher, I'm able to inspire the Indigenous kids within this school. The kids learn about their culture as well, which is really important for them. I can be myself and I can really have fun with the kids and make it enjoyable for them all the time. To sum up teaching in three words, I'd have to say that it's electrifying, challenging and of course rewarding. If you want to change lives, if you want to inspire people, if you want to make their learning fun and interactive and you just want to have an awesome life and be a teacher for sure. My name is Charlie and I'm a proud Indigenous teacher.


This is Think Tech Hawaii, Community Matters here. Okay, we're back, we're live, and we have an amazing first time only show. We're having a show with Jeff Grad, World Traveler, eating lunch. I mean, we could have been watching people getting a haircut, but instead we're having Jeff Grad eating lunch. And it's okay, Jeff, you can eat during the show. Welcome. Thank you very much. If it had been me just having a haircut, it would be a very short show. Yeah, same with me. We do have something in common. Amazing. So anyway, first you said you were going to discuss the new DROA form, which you have on the table. But then we thought that's probably not expansive enough for our discussion. So here on Global Connections, we should talk about more global things. And it so appears that you had just come back from Alaska, because everybody is going to Alaska and we need to compare notes with you. We've had several shows about Alaska.  So can you tell us a little bit about your trip to Alaska, Jeff? Well, my trip was on a ship, just like the one that you were on with your lovely wife. And we did it with three generations.  And I thought, you know, that would be an unusual way to go on some of these trips. But it turns out that that time of the year and August and July, you know, kids are on vacation and it's really a great family-oriented vacation. And usually, if I go on any of these cruises that people tend to be older and less fit and less energetic, but this one was really good. So I'd say it's really something that's a great family trip and especially for three generations. And so, yeah, I'd really encourage it. Yeah, yeah. Well, you know, our trip was on the Norwegian Sun, which started in Seward, which is to the southwest part of Alaska, and then worked its way all the way to the northeast, the rather southeast part of Alaska in Vancouver. It was seven days. We did not take the round trip. Did you take a round trip? No, actually, we took the same trip as you did in reverse. We actually started in Vancouver and then we ended up in Seward. And as I mentioned earlier, once we get off the ship, then my wife and I took about a two or three hundred mile trip north. And we went up to Denali, which is the Great Mountain and the Great National Park and maybe the biggest national park in the United States. And that was also a very interesting experience. Yeah, Seward, 1867, Seward's Folly, 17 million acres, two cents an acre. Really? It was a great bargain. They don't do that here in Hawaii. Yeah, well, at that time they probably could have done a pretty good deal, but you're right, now that's a very good price and it's not quite such the Folly what with all the oil they discovered and they had a gold rush of two along the way. And there's a lot of good stuff going on in Alaska. Yeah, what struck me is so different and interesting. Here we have an island state with water between all the islands. But in Alaska, you know, it's almost the same kind of thing except it's not water, it's forest. And there are no roads between a lot of cities. Only way to get around is by airplane and boat along the coastline. Well, one of the most remarkable things I think is that they have Juno as their capital. And the only really way you can get to Juno is by boat or by air. It seems like a difficult way to run a government. I guess technology has helped them because they can talk on, you know, the phone and mobile and internet and whatnot. So that works. But I was amazed the same way. I was also amazed.  So we were walking around Juno one morning. It's raining. It's cold. You know, it's a surprise for somebody from Hawaii. And this is the shop right across from our coffee shop. We're sitting here having coffee and it says no miners permitted. So what's this about? Can you guess what it was? Oh, maybe it was people who used to be gold miners perhaps. Only that. No, it was marijuana. Not the medical kind, the recreational kind. So it's very interesting. It was closed at the time of the early... Not a bad break. I guess so. It would have been interesting. I would have felt so guilty, you know, walking across the street and having a talk. I wouldn't have done that. But it's just very interesting how that state is in a way more, you know, more band more progressive than we are here. Well, it's interesting, the people that are on the ship, though, are different than the people who are going on land. They tend to be a little bit more upscale. There's a lot of middle America that gets to Anchorage. They rent an RV for often. And then they and their families go up to Denali principally. I mean, I've been to Alaska on a couple other occasions, mostly for fishing purposes. And we did a lot of flying in and flying out of remote areas. It's a great place to go fishing. And eat fish.   And so where do you think that the lodges food all came from? Flown in. Well, it came in from Seattle, the Costco. Yeah. Pretty interesting. It was pretty good food. The lodges are well known for the quality there and the lifestyle. We had crab, dungeness crab that was really out of this world taken out of the inside passage there. And my favorite of course was salmon. I mean, that would give me a town along that way. Yeah. Past Juneau or rather southeast of Juneau. Yeah. The salmon capital of the world. That's exactly. That's the one. Scalloway? No. Skagway. That's not the salmon capital. It begins with a K, I think. Oh, Ketchacan. That was really interesting. They had a lot of restaurants serving a lot of salmon. Well, they get a lot of salmon. There's more salmon can there than any other place in the world at one time. Yeah, maybe not anymore. But the salmon we had was really good. It was just beautiful salmon. Well, it's beautiful salmon until you watch them go up to streams and spawn. Yeah, why?  And so you're up in the streams that are several miles inland and there's a lot of dead fish. And not as they go up these streams and these rivers, they become quite emaciated and not very attractive, although the bears like them. Yeah. That's why there are a lot of bears that time of year out having a big feast. Yeah. Did you stop at Icy Point Strait? You don't recognize the name. Was it Indian Island Indian Village? Oh, I don't think so. I was fascinated with that place. It was an island and it was owned by the Indians. It was not a reservation, but they were Indians. They were, oh, I'm talking in the name of the tribe, Tinklit, Tinklit. And they're, you know, throughout Alaska they were in every town. Well, we stopped in the Anchorage Museum and they have a special, they have a number of the tribes, but Tinklit is certainly, that's one of the three or four better known tribes and really good, very good museum actually, really good museum. There are some very interesting, there's a lot, there's a great history, a great tradition in Alaska. And it goes back a long way and some very exciting and maybe unpleasant things have happened in Alaska. You mentioned Skagway. Skagway is a town that was pretty raucous for a long time. And the photographs, early photographs of how life was in the mud streets of Skagway, a lot of rough and rady, a lot of fighting, a lot of rady. I think that's where the gold rush was in the Yukon. And the Yukon, so they had actually a train track that went from there, it was Ketchkast Skagway. Skagway. Yeah. Before they had it, it was a very difficult walk for the miners. A little bit like Australia in some ways, they wouldn't allow a miner to go into Canada unless he brought a lot of gear with them. It was very hard to bring gear to go over these passes and might take 10 or 12 times before they could have enough gear to get over to where the gold was being mined. But the people that really made the money turned out with the people that were servicing the miners, not the miners themselves. So taking their last coins. It's interesting that that's the feeling I had too, that the miners in the gold rush there, they didn't really make money, they suffered a lot though, they worked so hard. They braved all kinds of weather and terrain and what. And trouble because to get from Alaska to the mines, you had to go through Canada. And that's an international boundary. Well, it was very steep. The area to go through was exceedingly difficult. And that's why they built that train. I forget what the name it was, something in Yukon. White, something white, white trains. Yeah, it could have been. It's good. Yeah, and they had, did you go on the excursions? I mean, every stop there were excursions. We did some of them. We actually did a helicopter trip where you land on one of the glaciers and you get out and walk along the glacier. And that was quite interesting. I've been to Alaska a few times and I can see the dramatic change in the glaciers, particularly at Mendenhall Glacier. Yeah, that's beautiful, that one. But that one is, it's almost a mile from where it was before, miles back. Do you see them falling into the water? Oh yeah, they call it capping, I think. They make a lot of noise as they go into the water. It was pretty interesting. It was interesting how close the ship got to it. The ship would sort of back into that and it really wouldn't be too far away. And you'd be close enough to hear the sound and see the thing shear off that way. And I couldn't, I mean maybe this is wrong, maybe you know more, but I couldn't help but think this is part of the same process of climate change. Well, it's partly a movement of a glacier anyway because it's on a slope. It becomes a glacier when it's on a slope and then it does sort of move. I mean those glaciers, you know, one time when they had the great glaciers, they went all the way into New England so they go a long way. But I was struck though with first the remote wilderness aspect of Alaska. I mean it's the biggest wilderness in the country all by itself, huge. And the beauty of it, it's quite beautiful. Well Denali is particularly that way. Talk about it, what's there? Well, it's a national park and there's about a hundred mile road of which maybe twenty miles, first twenty miles going in from the north to the south is paved and then the rest is not paved and they only allow, they don't allow motor vehicles other than a couple of buses so they have a bus that the national park has and then there's a couple of private vendors who I think were there before the national park and they give a tour. And because there's so little traffic that goes through there, the animals don't get very spooked when they see a little bit of... That's worth it right there, out along. I would say we saw, you know, wolves and we saw bears and we saw bears eating elk and so all kinds of pretty interesting stuff. Was the Forest Service, the United States Forest Service in residence there, did you see them? The Park Service. Park Service. Oh yeah, very important up there. And then at the end of the road you can then board the bus and come back but it's a hard road for people like me and so we ended up taking a fixed wing airplane ride back and then they go back up to Denali, the peak. Not only about 25% of the people that get into Denali they'd ever see the peak because it's so covered by clouds and storm and weather but that was a beautiful trip, I'd say. That's pretty a trip by helicopter. That was a fixed wing but it was a beautiful trip. But where can you land? A little water? Well, you could but there's actually back at the town where Denali at the north an end that has a nurse trip and they don't have big airplanes that go in there but there's a lot of small airplanes. I think, I forget what the number is but it's very hard. One out of eight Alaskans has a license for an airplane if they don't already own one so that's one of the easy ways to get around and the bush pilots. The distributed transportation industry is what it is. Everybody has a few airplanes as a result they all network together and the place lives. It reminds me also of the notion that in Alaska because of the weather and the seasons and the remoteness people are into a barter kind of economy in many places. You mean like a cocktail lounge? No, I'm serious. You said a barter? Oh, barter. I did see that in a couple of places I didn't notice it as being so prevalent but I did see it a few places where in most places you don't run into it at all. Bars are an important thing because it's pretty dark and it's pretty cold in the wintertime and there's a lot of camaraderie. I think there's a lot of fraternization among people in Alaska that have a lot of loyalty to one another. Yeah, I agree and that's year round and maybe especially when the tourists are not there. Let's take a short break, Jeff. This is Jeff Grad. He's a world traveler. We're talking about traveling in Alaska and seeing the beauty of that place especially now when it's jeopardized by climate change. We'll be right back. What are you doing? Research says reading from birth accelerates the baby's brain development. And you're doing that now? This is the starting line. Push. Read aloud 15 minutes. Every child, every parent, every day. Welcome to Sister Power. I'm your host, Sharon Thomas Yarbrough where we motivate, educate, empower and inspire all women. We are live here every other Thursday at 4 p.m. and we welcome you to join us here at Sister Power. Aloha and thank you. Okay, we're back. We're live. We're talking about Jeff Grad and his world travels and the trip he came back from most recently is the Alaskan trip on Crystal now which is a great passenger line. It applies the same ports that I went on a few weeks ago and Caroline Lee went before that on another trip also on no region. But I want to mention is the retail. You know, you get off these ships and these ships hold a couple thousand people.  The first reaction is, gee, it's dark. There's cloud cover. You can't see the peaks of the mountains. You see, you know there's snow up there somewhere. But it's not like Hawaii, you know. The sun is not shining. You travel on the ocean and it's dark and it's raining, it's misty, it's foggy. And at first I said, gee, you know, we have the wrong time, wrong place. This can't be, you know, this is not what we expected. But then I realized, I don't know if you have the same experience. Maybe you had better weather than I did. But it's the deal. That's the way it is and you have to see it that way because it has its own beauty. And don't expect the sunshine all the time. What was your weather like? It wasn't terribly sunny, but it wasn't terribly rainy. And it was a cloud cover, which in a lot of ways is pretty good. You know, I got enough sun living in Hawaii, so it wasn't, I didn't wear my shorts much. But I thought the weather, the weather in Anchorage actually is pretty similar to being in Vancouver and probably in Seattle. They all seem to get a lot of weather that comes in off the Pacific and they get a lot of it. Did you get the piece about Anchorage with the low buildings? The buildings in Anchorage are like two stories high no more. And why is that? Because they had some really devastating earthquakes up there. It's a big earthquake zone. Yes, it is. I think some of the worst volcanoes have actually in earthquakes have occurred up in Alaska. I didn't know that. I don't know why, but I should have figured that out. When you think about it, the whole Pacific region is bounded by earthquake zones from one end to the other, including the West Coast and including Japan. It's the same plate, I think. Sub-sub-sub-sub-sub-sub-sub-substructure. So, the thing about the retail that I was mentioning during the break is that we found my wife was interested in the retail. Not that we bought anything, but she was interested and so we would go and talk to shopkeepers. Many of whom were from Hawaii. Am I kidding? It's a little trip they do. They go there, they come back. Depends on the season.  Anyway, found that a lot of the shops are, what do you call it, pop-up shops. They might be in pretty nice spaces. Yes. I mean, improved spaces. But you're right, they're popped up in a sense that they're only there during the ships traveling in and out season, which is probably a better part of 90 days. So they have to make it. Well, it's not just the shopkeepers also. It's the people who are providing all the land options, the helicopters and fixed trains, and a lot of kayaking, things like that. They're people who go fishing. And it was, yeah, it's a short season, but they have to make it during that 90 days. And so things are pretty expensive, even relative to Hawaii, I would say, that they're pretty expensive. Yeah, it's true. And so you have to be careful about what you bought. And one of the things that I noticed, at first I couldn't believe it, I couldn't understand it. I still don't understand it. Why shop after shop after shop from diamonds and jewelers, left and right? Why? Maybe this is something that spilled off the truck during the gold rush. Maybe. But diamonds, they don't have diamonds in Alaska. Diamonds in this whole continent. Why so many diamond stores? Well, I think they've got a lot of people who get off these ships that have time in their hands. And money in their pocket, burning a hole in that. That's right. I mean, I always wonder when you go to a fancy resort, there's always a lot of art galleries. Because who has time other than when you're on vacation to really spend time in an art gallery? So yeah, it's a pretty stucie, a lot of jewelry. And then a lot of other stuff, it gets pretty repetitive. They're very typical deals, typical things. You know, on the ships, there were art auctions on our Norwegian sunship. And I had the feeling, I'm curious about your experience, I had the feeling that they knew that you would feel constrained because it was a limited space amount, amount of space on the ship. So they had to entertain you. They had to give you stuff to do. They had to make a plan of the day that kept you occupied.  And television wasn't so great because satellite and all that. So they kept on doing things, entertainment, music, art auctions, so many things that keep you going. And they would give you this plan of the day thing to keep you occupied, as if you needed to be occupied. I mean, you could read, I did. But it was not designed for that at all. Would you do all day, Jeff? With the kids, I'm sure it was fun. Well, the beauty to these ships in Alaska is that they have a program set up for the kids. So although we did spend a fair amount of time with the kids, I think we probably spent as much time as they wanted to spend with us. And the kids were nine and seven. And it just works perfect. If these kids had been 15 and 20, they would have nothing to do with these in-house camps. But I think I had sort of expected it on a Disney cruise. But I was a little surprised that on other lines, they would have children's programs. And I would say that was certainly what the kids did most of the time. What did I do most of the time? I did a fair amount of reading. And they have a gymnasium. I used the gym maybe three or four or five days out of seven. And of course, there's hardly an hour or two that went by where I didn't have an ice cream cone, something like that. It was a vacation after all. Yeah, I mean, it was, I'm sure, eight too much. How was the food? You know, the food was good. It's a pretty high end. You know, after seven days of that, I think that was enough for me. But I think a lot of people on these cruises go there with the idea that they're going to really chow down, as they say.  You could, yeah. Did they have formal dining on your ship? They did. They had some formal and some not so formal. Have to wear a coat and tie? No, that's pretty, the cruising industry has found they come around to the rest of the world. They call it freestyle. Yeah, well, cruise wear or something, but they, in fact, not only that no ties or even jackets were required, so that was quite a surprise from the days when you expected that you'd have at least one or two formal evenings. Yeah, yeah. On the Norwegian Sun, you know, they had the stock restaurants where you could chow down all day and all night, mostly. And they were located in various places around the ship. They also had these specialty restaurants. Where you'd pay extra for that particular meal. It was actually cheap, because it's just extra, in addition to the meal you might otherwise have. And they were pretty good. Some of them were really first class. Yeah, they had one on our ship. It was actually a Nobu restaurant. Really? Yeah. My favorite of all, wow. But again, they had a little extra that you had to pay above what they figured the normal food rate was. But nonetheless, as you say, it was pretty reasonable. What about the service? There's always a question. You expect they're gonna kiss your feet because this is after all about service. Was it like that? I mean, the feet kissing part. I didn't have too many, maybe one foot was kissed along the way, but for the most part, I don't remember that as an issue, but people were very accommodating and the service was quite good and quite nice. I was really interested in the international polyglot of the crew and the amount of the passengers. They were from everywhere. They were from everywhere. You could hear every language spoken. The crew were the... The crew and the passengers. The passengers, yeah. The crew tended to be on our boat with a lot of Filipino help. Yeah. I don't know how it is on your ship. I know some of the ships have Indonesians and they have some Scandinavians, some Eastern Europeans.  I really like the polyglot of it and you get to talk to them and they talk to you and it sets up a kind of international community around you and you feel like you're traveling. You're liberated, emancipated. So this is not the only trip you're taking this part of the year. Where else are you going? I'm actually gonna go next this month to a place called Pulia. It's southeast corner of Italy. And it's, yeah, I'm looking forward to it. It's mostly along the Adriatic Sea and we fly into a place called Bari, B-A-R-I, which I had been to as a youth because it was a place to catch ferry boats to the old Yugoslavia. Oh, wow, yeah. So it's not, that area actually as a crow flies isn't very far from the old Yugoslavia or even Albania. Yeah, Croatia, the Croatian crow as they say. Actually, I went to Dalmatia in that area last time. Very interesting. Well, I hope that's a good trip for you but I know if it was me, I'd be looking at Europe to see the changes. I'd be looking at Europe to see the migrant issue and how people are reacting to that. I'd be looking at Europe to see Europe of 2017 because it's different than it was, say, 10 years ago. Oh, yeah, it should be an interesting trip. And this whole area is what they call the Metzo Giorno. So it's, you know, it was really the poorest section and the section that needed the most help from the Italian government. So I haven't been down there for a number of years but I'm sure it's improved over when I was last there which might have been now 25 years ago. But it was a real down and out area but physically it's a beautiful area to travel through. Actually, I think it raises almost 60% of the grapes that are used for wine in Italy. It's not a bad thing. Yeah, so that's a good thing. Enjoy that. Well, I hope they have internet and I hope when you're there you watch thinktecawaii.com. I wouldn't miss it. I don't miss any of your shows. All right, he's not kidding. Thank you, Jeff. Okay, my boy. Good to have you. Nice to be here. Wonderful, lunch together. All right.


So first things first I just want to thank all those channel supporters that have jumped on my Patreon account. I launched that a few weeks ago now to think I've already got eight people that have jumped on board. Greatly appreciated. I'll put your names up on the screen and later today I'll be drawing the first giveaway for that group of people. Much appreciated. Secondly, many of you will know that I had a cycling coach come up and stay with me in the Sunshine Coast about a month ago now and I'm currently putting together an online course, Cycling Fundamentals. We're calling it becoming a smarter road cyclist and as a lead-in to that course to wet the appetite I'm creating a bit of content on this channel. A couple of weeks ago now I published a video which is highly successful number one mistake cyclists make with training and today I'm going to share with you a simple way to get stronger on the bike. So I'm at the bottom of a hill climb and today I'm going to be doing hill repeats. So let's just say you've done your base training and I'll link to that video below for those who missed out on it and you want to start getting stronger on the bike. Now you can do that with bunch riding but you'll only get to a certain point and I'll explain why shortly.  Now there's a couple of little tricks that I do while I do my hill repeats. This is the way I do them. This is help me become a stronger cyclist that I'm going to share with you and I also got a bonus tip at the end of the video but out of the nine repeats I'm going to do today I'm going to show you two on the GoPro that show you sort of separate things that I'm going to be doing. So let's get into it. So I'm just approaching one of my hill repeats here. This is repeat four of nine to be exact and on the screen you can see from the left time of day I've put that there more so so you can see the time of effort and also time of recovery. Ideally I would suggest doing this at an earlier time of morning to miss out on any potential traffic but I was a little bit behind this morning thanks to the drone footage and I do have a dedicated bike lane here. We have cadence speed power gradient and also the hill repeat course. Now according to Strava this climb is 520 meters in length at an average gradient of nine percent and about two minutes in length. Now I wouldn't recommend this type of hill for somebody who's just starting out with these style of hill repeats I'm about to explain to you. Around a one minute climb is a great starting point with an average gradient of say between six to eight percent but for me I've been doing these for years and I have conditioning and as a result I like something that's a little bit nasty which is what this hill provides. I'd like to share a couple of big things I'm doing here number one I'm letting the hill come to me I'm not attacking it I'm going to absorb every single part of this beast sitting in the saddle the entire time engaging my leg muscles including my core keeping my body super tight head up and looking forward at all times. Number two and this is a big one my cadence is low I'm in a heavy gear between 45 and 60 cadence why is that well in this session my focus is on the muscular system or really it's the musculoskeletal system which are two separate systems that work very closely together and are super important systems that will enable us all to get a lot stronger on the bike hence the title of this video but most cyclists and I used to be one of them tend to neglect working on the system with a typical cadence of around nine to a hundred attacking hills riding fast in bunch rides meaning the predominant focus is always or typically the cardiovascular system with cycling specific muscular strength being neglected. Now this particular hill plays some games with me here as you may have just seen it partially flattens out and then it lifts again which sort of forces me to lean back into my cardio system and then I'm back into my muscular system so it's a grinding hill it hurts a lot but I absolutely love it because I know it will make me a stronger cyclist while my focus here is more on holding good form and low cadence I'm hitting roughly my top nvo2 max or anaerobic training zones which is zones five and six while I'm cruising down the hill now in my recovery time I wanted to briefly mention the last training video that I made the number one mistake cyclists make with their training and you'll know in that video I emphasize to maintain a consistent pedal stroke to try and mitigate free pedaling in order to build a solid base however this session is a lot different that constant pressure on the crank you have with base training is a lot different here so let me quickly share some commentary from Luke at Metz performance consulting on this topic what we want to do is accumulate lactic acid have a partial recovery and then get it back in there again okay by doing that you're going to force your body to actually become better at tolerating clearing that lactic acid so instead of going from two five to five six we go from two five to three five then to four and then we jump up so as you heard what I'm doing here in addition to building muscular strength on the bike I'm also teaching my muscles how to tolerate lactic acid better so really this two and a half to three minute recovery period I'm taking it easy letting the lactic acid back out of my legs before I bring it back in now if you love bunch rides and I certainly do there's no doubt you're bringing lactic acid into your muscles during those sessions but I guarantee the efforts you are doing in the bunch are unstructured and if you're not bringing lactic acid in and out of the muscle in a way that will optimize your system's understanding of how to tolerate lactic then you're missing out on an opportunity to properly train yourself and here I am at my U-turn corner about to roll up and start my next repeat so the second repeat I'm showing you here I want to share with you what I do every third repeat out of the nine that I'm doing and this is actually repeat three that I'm doing out of the nine here I would not recommend this for people just starting out for people just starting out you might go do five repeats in your first session at a cadence a little bit higher of maybe between 70 to 80 in a perhaps a lower zone your threshold zone just start getting used to how this feels then as you improve your strength and form lift the number of repeats start slowing down the cadence increase your reps and then you can look into what I'm about to show you so just jumping forward here at the top of this hill with about 50 meters to spare I'm going to rip it out of the saddle now you can do these seated as well but what I'm doing here is going deep into my neuromuscular system which is directly responsible for the recruitment of muscle fibers and the more muscle fibers that can be recruited to perform certain tasks the more powerful that muscle group will be and while these will fatigue you and you will particularly feel it towards the end of the day I guarantee you if you start implementing these into your session you will get a lift not only in your sprint but across all facets of your cycling so as I roll down the hill again let's just ponder for a minute when was the last time you rode 18 minutes in your top end zones in a heavy gear with three 10 second all-out sprints I would probably guess most people would have never have done this before so if you haven't go start training this style of ride once a week if you don't have a hill you can do it on the trainer make sure the days before and after this session are easier ones and please come back to me in a month or two and leave a comment below this video and let me know just how much stronger you've become I truly think you'll surprise yourself and as a follow on we're only just touching the surface on efforts here there's so much more we can discuss so let me know below if you're keen to have more of this type of content so there's the hill I've literally just finished off nine repeats which was pretty hard work it went pretty quick when you've got a countdown repeats I find the sessions go fast but with these types of sessions because you've you've worked hard you've deserved a little treat this is my bonus tip I'm going to take you where I take myself after these types of sessions so this is the most exciting part of the session because it's finished I've just done a 20 minute warm down home's five minutes down the road and I'm around the corner from my favorite raw organic pancake place I'm about to treat myself to a Snickers pancake which I do after every hill repeat session you know I gotta survive you know the mother do strive and when I'm hugging the block you know we bound to collide this is the cold out here southern California cold out here though we are cold out here huh so they rush for the best secret uncapped this is taking off for having a motion


Hi, I'm going to talk about adaptive security via deletion and attribute-based encryption. This is joint work with Richard Goyo and Brent Waters. So consider we want to do public encryption in a large organization where everyone can send a secret message to another person by encrypting the message with respect to that person's public key. A naive way to realize this is just let everyone publish their public key in a directory. However, this approach may be very inefficient when we want to send a message to a group of people we need to encrypt and send a message to each of them. Suppose these group of people actually have some common features. For example, they all work in the same research group or they are all under or above some certain age. We can probably just send a message, encrypt a message to the people with all these features that can be encrypt, but others without these features cannot. Such a notion was formulated as attribute-based encryption in these two papers, Sahai Waters 2005 and Goyo Pandey Sahai Waters 2006. In an attribute-based encryption scheme, every user has an attribute as an NB binary string. And we have policies, which can be seen as boolean functions that take in NBIT input. These boolean functions evaluate on the attribute and output 0 for reject and 1 for accept means the attribute satisfies this specific policy we want to deploy. To issue keys, we run setup to generate the public key and the master secret key. Using the master secret key, we can derive secret keys associated with different attributes. And to encrypt, we use the public key and we encrypt with respect to a certain policy and the message we want to put into the ciphertext. The policy can be like decryptors must be all graduate students and it expresses a boolean function of attributes as we mentioned before. And only users with the secret key associate with attributes where this policy would evaluate them on them to be one can decrypt the ciphertext and the rest cannot. And this formulation above is often called ciphertext policy attribute-based encryption since the policy, the functionality is embedded into the ciphertext. There is also a dual formulation called key policy attribute-based encryption that embeds the policy into the secret key. And the attribute into the ciphertext. And both of these have constructions that have a lot of applications. For both of these formulations, we also have two levels of semantic security requirement called adaptive security and selective security. So adaptive security is actually what we usually want in practice and it's also called full security. The challenger generates in the security game, the challenger generates a public key and the master secret key. It gives public key to the adversary. The adversary can then make queries for secret keys corresponding to some attributes he chooses and for polynomial many times.  And this query stage can happen again after the challenge phase. In the challenge phase, he sends in a policy and two messages of his own choice. But this policy must be one that none of the attributes he has queried before or he will query in the query phase after challenge phase. Like none of these attributes he will query will satisfy this policy. And the decryptor that encrypts one of these messages randomly with respect to this policy, the adversary gets the ciphertext and he's not supposed to guess which message is encrypted. This definition, even though natural, is in fact not easy to realize. Therefore, people actually turn to a weaker security notion called selective security. Adversary in the selective security game, the adversary has to first send in the policy it wants to attack on before it sees the public key. And in the full security, it happens in the challenge phase where the adversary can see the public key, can make queries, and then he chooses the messages and the policy. And here, he has to send in this policy and before he even sees any public parameters. Everything else, every other stage, is the same. And many of early works would first try to build this selective security and later works move on to reach adaptive security. Next, we can look at the line of works that try to build a secure ABE. We look at both group assumptions at lattice and both selective and adaptive security. So as we mentioned, early works first to build selective security in terms of group constructions. These early works build selective security from bilinear DFA helmet. And later, there was this well-known due system technique introduced by Waters. And adaptive security was realizing these later works for policies in NC1. They're based on different types of decisional group assumptions. And however, the reliance on decisional assumption seems to be inherent when using this technique, whereas in these early works that only have selective security, we can actually build from search assumptions. Moving on to the lattice side, these works realize selective security from lattice for circuits. However, it was not until recent two years that we finally know something of adaptive security from lattice. And just to mention here, this Boolean searching scheme was actually had a tag in last year. But we would leave it here because it will be actually useful when we talk about looking forward, when we talk about our construction. And so the recent breakthrough, we mentioned, was separate in 2019, realized adaptive secure ABE from lattice. Even though the functionality realizable is only a subset functionality, it is a step towards adaptive security. And it's a different approach from all past approaches. We therefore ask the question, can we expand this approach in some way to make adaptive security hold for more general cases? OK, in our work, we simplified and expanded the framework of realizing adaptive security following a summary 2019 paper. We showed that in a simplified framework, we can instantiate the adaptive secure ABE for subset functionality from both search by linear assumptions and lattice. And we can make the whole framework more clear and understandable. What's our high level approach? Our high level approach is just combining two building blocks in an interesting way. The first building block is selective secure key policy attribute-based encryption with a property that we call deletable. And we just require this underlying key policy ABE scheme to be selective secure, but it needs to be for NC1 circuits, which we already have from some previous papers we mentioned. And we will talk about what deletable property means and how we can realize that from previous work. The second building block is a constrained PRF with deletion conforming property. We'll also talk about that later. And together with these two, we can realize adaptive secure ciphertext policy ABE. OK, now let's go to our first building block, deletable ABE. We demonstrate deletable property as follows. Given a ciphertext, which is an encryption of a message M2 attribute X1, and we can view the ciphertext actually as a bunch of blocks, a composition of a few blocks. And then we can perform an algorithm called delet on the ciphertext. This delet algorithm will take in the ciphertext and the set of indices. It will delete the blocks in the ciphertext indexed by these indices in this set. For example, 2 and 4 here, and we just take away block 2 and 4. In fact, the number of blocks is equal to the length of the attribute. And each block is actually just associated with one bit in the attribute. So we can take a look at this delet thing the other way around. By looking at the attribute first, we can perform this algorithm called restrict that basically just remove some bits in the indices. In indices in this set given. We can probably replace these places with a special symbol like a bot. And then we have this encryption procedure that can encrypt with respect to an attribute that might have some special symbol bot and will still get us a valid ciphertext. And after we see these two different approaches of doing deletion, we say that they are actually indistinguishable once you get a ciphertext. So that basically means whether we encrypt, we first encrypt and then we perform deletion on the ciphertext by removing a few blocks or whether we first just remove a few bits in the attribute that encrypt to this deleted attribute where we can get another ciphertext. And these two ciphertext should be indistinguishable. We call such, we call an ABE scheme with such property. This delete procedure is actually restrict procedures here. And also this indistinguishability property, such ABE will create deleteable ABE. And we get to our second building block is this constraint PRF. Let's first look at a usual constraint PRF. What properties do we have? So a constraint PRF has constraints to do randomness property. So given an original key of the PRF, which we called master secret key here, we can constrain the key with respect to a function F. The PRF would evaluate correctly and normally on the constraint key when the input satisfy this functionality F that we constrain to. However, if the adversary is given a constraint key, it's not able to evaluate the PRF and inputs that do not satisfy the function. More formally, he cannot distinguish evaluation on these inputs using the original master secret key from any uniform random values. And here we only need a single key adaptive secure to do randomness. And another property we need is called adaptive key simulation. That is we let adversary choose a function F adaptively and there's a procedure called key theme to generate a simulated key for the function F. And it would give a simulated key indistinguishable from the real constraint key. That procedure only needs to know this procedure key theme only needs to know function F and security parameters and input output size of the PRF and no need for knowledge of any secret key information. So therefore this procedure can basically be done by anyone given the encryption of F and this will be needed in our encryption later on in our construction. Okay, and now we move on to some special properties we need for our construction to conform with our framework we call deletion conforming PRF. So firstly, we can constrain that when we constrain the master secret key we in fact just need to remove some blocks in the key according to a set of indices. So this would probably remind you of something we just talked about the deletion, the restriction on the attribute that we can just give that when we are given a set of indices we just remove some attributes, some bits in that attribute and this here we do the same thing to the master secret key. But how do we know what indices to delete? How is this created for F? And we actually have another procedure that takes in the description of F and it would just output a set of indices that tell us what to delete, what indices we should remove from the master secret key in order to realize the constraint functionality for F. And secondly, we need a slightly special evaluation procedure that is we can evaluate the PRF on a hard coded input X using a special circuit evaluation. This takes in a circuit hard coded with input X and the PRF secret key as input. It can be constrained or it can be the master secret key and output a correct evaluation as if you do just using a normal PRF evaluation on the same key and that value X. Now we can build our adaptive secure ciphertext policy AB scheme from these two underlying building blocks, the deletion conforming constraint PRF and the readable key policy ABE. The first way we can start by talking about the Keygent algorithm of our ciphertext policy ABE. Our Keygent algorithm takes in a master secret key which is just composed of PRF secret master secret key and the deletable ABE master secret key. And to derive a key for attribute X, we first compute this PRF evaluation on X using the PRF master secret key and we get a value we call T. Then we run the underlying table ABE's Keygent with respect to the following policy. Just recall that this is a key policy ABE so the key derivation algorithm is respect to a policy. This policy FXT takes in a secret key. Looking forward, this secret key will actually be a constraint PRF key that we will generate and it outputs one if we have this PRF evaluation using the hard coded circuit of X or input of the secret key SK. I'll put something that does not equal the T we computed previously and we output zero otherwise. And then we need to encrypt the message. What do we do to encrypt? Well, we just, we're taking the policy F and we can compute this simulated key using the PRF key simulation algorithm and recall that this can be done by anyone because it only needs the description of F and security parameters. And after we get the simulated key, we just encrypt the message using the underlying deletable ABE's encryption with respect to this attribute of the simulated key. And to decrypt it's simple we just run the underlying deletable ABE decryption using the secret key associates with that previous FXT we talk about. We get such a secret key and we can decrypt. And it's probably not very obvious at first sight why correctness would hold for our scheme. We refer the orders to check the details in our papers and if that takes use of these non-cluding properties of the PRF simulated key and the real master secret key. To show security, we basically hybrid as follows. So in our first hybrid we switch the attribute used during encryption from the simulated key to a real constraint PRF key. So recall that in our real encryption we need to do something, we need to encrypt it to a attribute and then we can generate by anyone because this is a public key encryption procedure and we can just run the key simulation on the function F. However, in our hybrids we can switch it to a real constraint procedure on the master secret key with functionality F. And this indistinguishability will just follow from the key simulation property of constraint PRF. And secondly, we use the restrict algorithm to perform the constraint functionality thing on the master secret key of PRF. And we have mentioned this before in our deletion conforming constraint PRF these two operations are actually just equivalent. And this is just a basically removing a few blocks from the master secret key using the set of indices that we need to remove for F and that would just perform the functionality of constraining master secret key to F. And finally, notice that here in the previous two hybrids we performed this restrict or say removal on the master secret key which would give us this attribute that we want to encrypt to and then we encrypt respect to this constraint key attribute. And in the final hybrid we switch the order of deletion. We first just normally encrypt with respect to attribute that is the master secret key of PRF without any constraining using the deleteable ABS encryption. And then we run delete on the ciphertext using the indices to delete for F. So we can still, you know, taking F we can still just generate this set of indices and that wouldn't disturb that wouldn't really affect anything. We can do the deletion on the master secret key or we can do the same deletion on the ciphertext. And then this follows from deletion and distinguishability of deleteable ABE. And finally, we can actually use this to break the selective security of deleteable ABE and suppose the adversary can break the adaptive CPA security of our ABE scheme in the final hybrid. And we can use it to break the selective SAPA security of the underlying deleteable ABE. And finally, how do we instantiate our building blocks? The first thing is deletion conforming constraint PRF. We can realize it a subset functionality just following the construction in these two works. And secondly, for deleteable ABE we can realize that from different sorts of works we can actually modify the following schemes into a deleteable ABE scheme and into deleteable ABE schemes. For the group side, we can modify the GPSW 2006 paper which uses a search assumption on bilinear groups. And for the lattice side, we can do both Boyan 13 and the BGG plus 14. Even though actually recently, as we mentioned, there was this tag on Boyan 13 paper but that came out after the first draft of our paper and we still leave this example in our paper just for the illustrative purpose to see how the deletion, how the deleteable ABE would work. And regarding related works actually, besides all these past works we already mentioned, there was also a concurrent work by Katsumata, Nishimaki, Yamada, and Yamakawa that extend the functionality of SAPARI scheme into an inner product functionality. And they also follow the same high level approach as the SAPARI scheme. Finally, here's our summary. With adaptive constraint PRF, adaptive secure constraint PRF and selective secure ABE, we can realize adaptive secure ABE. But the policy is just a subsets constraint which follows from the policy we can realize for the constraint PRF. And we need the ABE to be deleteable but we can build such ABE from a bunch of assumptions both searched by linear and lattice. Thank you. That's it for our talk. Please refer for more details in our paper.