Hi everyone, welcome to the July 8th, Jeremy can you start recording please? Jeremy is not here. It's already recording. Okay, thank you, hi everybody, welcome to the July 8th UX Seek meeting. So today I'm going to go over the agenda. Everybody, we are all, we've all been here before and one of these meetings, so no presentations are required. So first of all, I wanted to give some updates on the status of the UX Seek work. I want today to go over the status of the Forum Tables to Deep Initiative VR. And I want to present the tables changes, tabs and tables changes agreed to appear today, we'll go into it later. And then I want to discuss if there's comment of every bit, if that's anything we can do for the next LDS, anything else. Okay, so does anyone want to have anything else to the agenda before we start? Okay, let's go. Everybody can see, well my screen, right? So, regarding tables to this, I've been putting, what did we leave it last week? So, basically, we decided that it was maybe a bit too soon to decide whether it should go into the LDS or not, or it should be merged or not. We decided to talk about it this week. Unfortunately, I tried to unblock the PR to fix the table UI breaking issue. I wasn't able to do so. I worked one or two, almost two days on it. I wasn't able to unblock it. I did put a noticeable amount of work into running ATH tests, PCT tests and doing a comprehensive code search. I've reported issues with almost around, I think it's around 30 plugins and there are just some plugins I didn't even report them. I need to do it. So, there was some work done. Timo also did some great working. He, in forward reporting, the JavaScript answers changes. The JavaScript changes are already in, into the Jenkins master branch. So, that's going to solve any possible need to rollback the PR and to simplify the, well, to reduce the final complexity and risk of the merge. So, that's where we left it this week. Did I miss anything? Okay. The JavaScript was released in the last version, so it's out there now. Yeah, definitely. Yeah, JavaScript was released in 2244. Yeah, so this week if we can get someone else to review it. And that just makes it far easier to rock to other feature toggle or rollback if we need to. Yeah, it's still weird recommend I think that the JavaScript, the CSS changes need a bit of fine tuning still. So, hopefully we will get to do it before in next week, probably, but we just didn't, we wanted to merge it before because it was getting stale. It was doing no good being just there. Okay, so if we've been trying to look into the, so I want to talk about the tables to the status of the PR. So far nothing has, from my point of view, nothing has fundamentally changed the breaking issue is still there. We did lots of groundwork so we have cloud is able to say that we cloud is we don't recommend it merging it before the next LTS or included into the next LTS branch. We would recommend it having a date done by the next LTS cycle, maybe merging it at the beginning of August. That said, we will of course, in no way shape a form, try to delay it. I try to delay it if the if the breaking issue, the breaking issue is fixed, or delayed merge delayed any inclusion in any in the LTS. We will support the community of course. We just recommend against it, and we may not use it in our cloud is in our Jenkins based products, because we cannot just there are lots of standing issues in in many plugins. Well, some of them I many of them I reported in the into the data tracker that we just don't have the reason we just don't have the resources to commit to fixing them in this summer. We will work on that after after the summer and in fact, we have already started some work with the idea. I did the comprehensive comprehensive code search and testing issues and reporting of issues with the tests. And we are already working on fixing some ATH errors, looking into errors, for example, right now we're looking into errors with formalizations and the promoted builds plugins. We just don't think it's we are just not confident into guaranteeing the quality by the September release. So we will let me reiterate, if the community wants to if team only you and the rest of the community you think it's a if the layout fixing stuff is ready, you think it's ready to merge. We will support you, of course, yeah, we just don't think it's right. You said one question. What if we added the feature toggle? I think it's a lot easier now that we've managed to separate the JavaScript and CSS changes. And yeah, similar to the bootstrap plugin, which has a just has basically two versions of the tags. Yeah, I mean, with a feature, it could work. Right now, I don't know how hard it would be. When I looked into it, for some changes to optional block, I don't think changes to watch, for example, optional block or radio block where forward ported, right? So, or advanced. So those we just two versions of the tag and just, yeah, I don't know, we don't have the resources to commit to it right now. As cloudies, we are not able to work on it right now. Full capacity, I mean, in the capacity needed, but if if somebody comes up with that, I will make it a priority to test it and to verify and to review it and, of course, from my side, I can commit some time for review and testing. But yeah, my bandwidth is also very limited right now because my time mostly goes to Jenkins governance stuff at the moment. Yeah, I'll do my best to review that. Most likely it will be just happening sometime on weekends. Yeah. Cool. I mean, once the CSS changes merged, I can take a look and see if a feature talk was feasible. It wasn't feasible when the JavaScript was there, but I think it's a lot more straightforward now. Yeah. Okay. Yeah, maybe maybe just a PLC with the entry advanced optional block. Yeah, so those videos are just showing high stuff, you know. Yeah. Okay, so yeah, I will, as long as you have a draft, I will look at it. I will make it a priority to look at it. Yeah, yeah, once, yeah, I'll take a look once CSS changes are in and I don't want to just to get the diff as small as possible. And I'll take another look as well just to see if there's anything else that can be removed is just to reduce it down as much as possible. Okay. So anything else? Do you have any opinion on this topic? You're muted. Actually, no, I'm not really using these fields very much since we everybody's now using pipelines and yeah. Okay. So for me it's good to change it. And yeah, I'm not sure if it's good to change it before the LTS, but yeah, I don't really care. It's okay to change it now. And we need to fix some plugins anyway. Yeah, okay. Okay, I can fix my plug in. So, yeah, I did report a few. Yeah, I didn't report some issues on the warning. Yeah, that's okay. Part of the code I looked into two years ago. So, yeah. Yeah, but if it's behind a feature toggle like Tim is proposing. So at this and the current state, the feature would be opt in at least for now, maybe even enabled by default and experimental UI, because why not. And we basically make it opt out once we have more plugins stabilized. Is it right? Do we want to enable it by default? We'd need to have just a review of the plugins and see whether there's any major plugins that weren't turning it off initially, probably turning it off initially is that no one's going to use it so you're not going to get any feedback. But if we've got some fixes in flight, it could make sense to just have it merged to make it easier to test and then enable it once a few fixes have been released. Yeah, that's a fair point. We have no way to promote experimental features. So, yeah, we can write a blog post or whatever but still the feedback would be not that high. So it's nothing like in GitHub where I literally get this big little blue thing up in the corner of my screen that tells me all there's a new feature and turn it on two minutes after they've released it. Well, I wish to implement such identification engine. But now we don't have one. I think that it would be really useful in general to have it. In my opinion, too many key plugins and high use plugins may break in or for me to comfortably recommend that it's opt-in. Sorry, opt-out instead of opt-in. But I mean, that discussion can take place once we are sure that's visible. I mean, I don't see a point. Maybe it's not that useful to discuss it right now. But the notification is good. Maybe I don't know if it's appropriate to leverage the current notification bell. I don't know if that's appropriate for that use, but okay. So, yeah, so is there anything else to talk about this topic? Does anyone want to chime in? Okay, so if nobody has anything else to say, I'm going to go ahead and move to the table changes. So not very big updates. Joe is cooking some things up in the design front, but he will show them. I'm sure he will show them next week. Sorry, in the next meeting. So today I created a draft PR for the revamp of tabs and big tables. One of the reasons he's in draft is that I'm not sure of some API choices I made. And because I haven't uploaded the design briefs that Joe showed us last week, I haven't uploaded to the JIRA issue. And I don't want to take a PR out of draft status without the proper design documentation. I think that's a good practice to do from now on our side. See the PR is there. Everybody's welcome to actually encourage everybody to take a look at it, at least from the code and everything. So I'm going to go ahead and do some quick showcase of it. This would be what the new tables would feel like. I truly believe that these new styles were really fitting within the rest of the UI, especially if you take into account the side panel, the hyperlinks and everything else, basically. Especially with hyperlinks. Maybe it's because I'm biased. I really, really like it. So this is what the planning table would look like. For example, let me go to all here. You may notice that I have a right and left align all these columns, because in order to improve legibility and accessibility. I have also, for example, here you will see that these colors, these color is the same as the breadcrumbs as the footer. This hover color is the same as the ones in the, that's not showing up. It's the same as the one in the sidewalk here. So it's, we're also moving towards a more consistent color palette, which is good. Yeah, and these are the tabs, basically. I encourage everybody to try. I really am really proud of the work Joe did with designing, and I think it's really nice. But we are open to feedback. Of course, everything can be improved and iterated upon. So we encourage everybody to give their feedback. Can you click on the updates tab? Yeah. So for some reason, this table feels fine to me, but the job table just seems to be a little bit funny with the header. Which one then? I don't know why this one seems okay. But if you go back to the main page, for some reason, the header bar just seems a bit out of place for me there. And where do you see the top left active tab? What does Celo just place it up? I think it's, possibly the color is a different color to everything else. I'm not sure. It just looks a bit funny at first glance to me. But I do like the design of the rows a lot more. I think that looks quite a lot nicer. Yeah, I think maybe it's because what you see here, you may notice that this is, there is this underlying this table doesn't, this step doesn't completely blend into the, into the header. And that's because otherwise it just wasn't possible without changing the styling of the table in relative to the, to the, to the tabs. Tabs were a difficult component to style, to be honest. I had some trouble working on them. But yeah, they are not perfect. I also introduced the ability to have a tab baseline to have just standalone tabs that have a whole, that span the full width of a container and then everything underneath them. One of the things I wanted to people to try and give feedback is because I wasn't sure how to do them is, for example, cases where the app by a part of the page has tabs but uses a pain frame widget. For example, this case, this is the thing I'm probably looking feedback or alternatives into what we should do because this is a weird one. I think that for this particular page, our strategy is to get rid of that move it to some way to global configuration. And as long as you keep it working, it should be okay. Yeah, I don't know. I just wanted to keep to styling. I would first remove the border but the reason I couldn't remove and then I realized this was supposed to be outside of here. But I don't know. I wasn't sure how to do what to do with this. What I probably do is I probably create a follow up PR in a few weeks, walking on the pain frame, maybe adding another border. I don't know, removing the border radius. If this goes through, of course, if not, if everybody thinks he should work on the pain frame now. I will, of course, depending on the people. We worry about this page too much. It's a kind of expert page. It doesn't work now anyway. Ah, yes. Yeah. Yeah, but also some user experience issues included, for example, HTTP proxy configuration. It's kind of figurable in a plagued manager, but actually it applies globally for your Jenkins instance. Yeah, it's so weird. So this part definitely has to move elsewhere. And for the rest, upload plugins, etc. Yeah, don't look too much as long as it works. Yeah.  As long as it works. I think it's overall, it's a huge improvement. If anything, I would invest your time on making those tabs look a little sharper. I mean, the underlying at the bottom, I mean, the border at the bottom of the tabs is more disturbing to me than the pain frame. Yeah. Yeah, let me work on this a bit. I think it was difficult, but I mean, just if you have a bit of time, that's, wow, to me that's the most visually. I did go into several options and that's the best I could do, basically. It's the best I could do. So something that I could try is, yeah, let me, so something that could be that I could try is, you know, just making something. Okay, I need to do something like this, you know, having a full width baseline. This is something that I actually added an option to the top bar to show the baseline. And it can also be shown by default. That's what they put look. So there is no way to make it look right right now in Jenkins, but I think that's a nice compromise. What I would actually do is I would put all of these on top. And on the other pages, for example, I would nest, I would keep the top bar on top and put everything in, beneath it. But that would mean a follow up PR, of course. I mean, overall it's straight ahead of what it was. I mean, it's much better. Yeah. Yeah. I have also created the corresponding issues into the dark team plugging. I don't know if you noticed him. Yes. So yeah, I encourage everybody to try. Everybody to give their thoughts on. And if there's any blocking thing, for example, if the top stuff is a blocking thing or something like that, then I can work with it. If not, we can iterate it into in the future. But yeah, I appreciate any feedback on this one. We just need two tables. And tabs. And with tables on me, I mean, big tables. Yeah, they will skip the big table class. So is there any other big table classes? So there's the jobs. So there's like the. This page. All of them. Basically, all of them, for example, this credential table. And yeah, let me go. This one, this one. Information. So all of these are effective. This one, for example, this one, this table revealed the need to use a proper semantic markup to separate the heading as the footer and the body of the table. Something that I may create a PR in there. I will probably create a PR after this one. To. To allow for. To have the body and the foot elements with proper styling. The users table decision information stable. And I found many other plugins that use this. So it's, it's, it's a target in the big table class was a allowed us to consistently improve the look and feel of all tables basically across the Indians. I don't really, I don't know how it would look if you just started the big table class to the to the other bootstrap tables. I don't know how it would look to be honest. Yeah, I should probably be okay. I'll try it. Normally, the things I'm using are not so young.  It's more light, you know, lines and which I'm not sure if it matches correctly. So I'm wondering why are you using the black header of Jenkins and not the blue one. You don't like the blue one or it's actually not the same black black. It's actually what the secondary button color, the secondary text color. The header line, the Jenkins header line, you are always using the old style and not the blue one with the, you know, because yeah, I'm because I'm showing in this off my local Dev environment. And I just, it just makes the, the, the command line entry 30 or 40 characters longer. So that's why I'm not running it. I'm getting revisited at some point soon about either better rating on us or enabling it by default. Yeah, I have something we want to talk into. Let's have a, let's have another point of order for today for now. Let's talk about the new header. So do we have anything else to talk about tables and tabs? Okay, so let's talk about the experimental header. So I think we already covered this a few, a while ago, Joe may comment on this one. We always say that the beginning that the header that we were 110% open to iterate over components, and that's something that's probably needed. The header and breadcrumbs components were developed at the beginning of the project. We didn't really have the full picture of where we wanted to go, what the color palette was going to be, what the design season was going to be. For example, we started using the robot the font and then when they probably will change it to the system phones. That will what I want to say is that it needs to be revisited to see and determine if it's consistent with the how the design system evolved. And if we want to keep it, if we want, for example, do we want to keep the blue header? Do people actually use it? Is it the right shape, shade of blue? Is it better to have a more darker shade of blue like we now have in the primary color? What do we do with the logo? That's something that should be discussed. Definitely. Because it needs to be turned on by default, otherwise you get very little feedback. Yeah, I mean, yeah, exactly. The feature flag UI that encourages people to turn along. Yeah, because right now, one of the things, one of the points of the feature flag of the UI feature flag was to enable just to hide changes that would be too controversial of the code break plugin. Turns out we were lucky and we didn't do that we didn't need it. We all the changes that we've been working on for the past five, six months, we were able to integrate into the mainline. Minimizing the effect they had on plugins. So, does experimental, does just a header color and logo change warrant, especially a feature flag? I mean, I don't think so either. So that's something we should talk about. Maybe we can make it a point to, Joe, do you think we can, do you think you could have a look at it and have a proposal or something for the next meeting? Yeah, for sure. In fact, Felix, this is something you and I haven't discussed yet, but I've been working on this sort of on the side and have updated designs for this, like we kind of talked about a couple weeks where the logo treatment is adjusted, the color treatment is adjusted, and also, if I remember correctly, font size on the breadcrumbs has some tweaks to feel more appropriate in the space. So yes, definitely, and we can take a look at those changes in the next six. Okay, great. So I will add it to the agenda right after this meeting. So, does, is there anything else to talk about this topic? One comment. So, yeah, there is a header. There is experimental your flag. First, I would prefer to keep the experimental flag regardless of whether it changes header or not. So for example, for tables to leave so we can use the same feature flag to enable that. And maybe for future improvements. Yeah. Yeah, I mean, what I want to say is that the right now, I don't want to fall into Jackney. Right now it's not. That's what I mean, and the flag is called Jenkins UI refresh anyway. So, I mean, for changes are big enough that I think they were on their own flag, or their own setting. And, yeah, I don't think I think just keeping the flag, we could incur into technical debt. I mean, if it's not needed, if it's needed and we find more users for it, of course, in the future. It also introduces a documentation burden and everything. Yeah, that's why I'm thinking about keeping a single flag so that we can document that he if you're interested in experimental you can set this flag. Yeah, the document would exactly include. Yeah, well, if we have more stuff, sure, right now. I think people are not people who say, okay, use this flag to enable the experimental Jenkins UI and they just see a color change in the header. People are not going to be impressed by that. Basically, so I think it's too little to warrant it. We can keep it and use it in the future, of course. Okay. So, if nobody might say we can move on to the next topic. Yeah, something I want to change. Well, what I'm not able to dedicate proper the need of the amount of time that they was to this. I do have some spare time. No, maybe I wanted to raise the point to see if there's I wanted to raise the question to see if there's any quick win. In UI wise or UX wise, we can do in Jenkins, something of tasks, a few tasks that take more or less a day or something like that. That we could do in preparation for the next LTS just small things that would be nice to have there are any ideas on this topic. I just wanted to flow to the question to see if anybody has any ideas on this one. It's the monitoring plug and link. It's not broken right now. Okay. Oh, well, that's something that needs. Okay, let me write it down. It's completely escapes its container. It looks horrible. Which one was that Tim? Sorry, could you repeat it? I'm monitoring management link on the managed Jenkins page. It was part of the managed Jenkins page rework. Broke it worse than it previously was. I don't have it. I don't, I don't think I have it. Yes, I, I, yes, that's the issue I recall an issue. Yeah, that was a bit of a misuse. If I recall correctly of abuse of markup that yeah, that's something that doesn't really look right. Doesn't look right. It's very broken. I didn't want to be harsh. But yeah. Okay. I was just browsing my instance looking for weird things. Yeah, I mean, one of the things that for example, I, I don't know. I think, I think that they would, I think we, we have a comprehensive set of changes with the sidebar tables and tabs and hyper things for the next year that users will definitely see change and the dark with the dark theme, of course, not, not a one day change but move blue ocean into regular Jenkins or something. Yeah, that's going to be hard. Yeah. Yeah. I think there's something in the community road map for that, but I'm not sure. Yeah. I'm not yet to be seen. Well, we've got a lot of feedback for Jenkins pipeline browsing improvements is a part of your years hug fest. Someone is interested to try and hug this topic together. I would be happy to scale something maybe in August and September. But yeah, right now there is no confirmed plan for that as far as I can tell. It's so hard to develop on it's so heavy. It's so difficult to even start it. For what is worth. Yeah, I just wanted to joke about blue bus microhug. I wanted to actually create a really small fork of lotion which would squash all the complexity that the rate of editing features actually just leave browsing and remove all the crappy dependencies like jr plugin so that keep it really concise and have it as a separate plugin. But yeah, I haven't went much beyond the concept. I tried to one of the, I, I, a while ago I tried to, to use the react to create a react with yet that you would use the lotion API and the lotion components to render them to render the the chart on a normal Jenkins plugin. You know, sorry on the classic can just be right. It wasn't that easy to reuse those that stuff I think we shared to just copy and paste the code and created from scratch. Yeah, that's not that's my insight because I did try it for a few days and they got nowhere. I've had a bit of a hack on it on dark theme work and they did manage to get development work by going but it was a pain and stuff didn't work for very well and it needs some dependency updates as well. The latest node and gulp don't work and stuff. Yeah, nothing is a tough one because I feel bad because every now and then I break it. Yeah, I don't want to break it that much dark theme is an incubating project. So personally, I'm perfectly fine with any breakages, especially if it helps us to facilitate feedback and to help and helps us to deliver something stable for the next LCS baseline. Yeah, dark things really easy to fix if you break it and it's also really easy to be compatible with both versions as well. So it's not really an issue. Yeah, but but what I bought and maybe what we could do is to add an official entry to a documentation entry. How to guide for for plugins to support dark theme. Because but what we would need because I'm pretty I'm afraid some plugins with just use the CSS variable without the fallback value. I mean, the plugin just will not work in terms of right. So that's something I'm afraid of. And also, for that we would need to choose official minimum CSS API a support the CSS variable API, and just productize it. I don't know if that's the right word. Yeah, make it official. It's just still being developed right now. So, yeah, the CSS API we can start documenting it, for example, in a web browser support policy, because we have this page so we can include something there. Yeah, yeah, I don't know what my point is for example right now we have around the theme file has around 200 300 CSS variables. I think it's in the order of 200. But I wouldn't call those as stable API maybe 30 of them are stable like link color link color all of those variants. But we just cannot say okay you can you have plugins to it's okay if dark theme uses them. It's a different thing if plugins depend on variables that are maybe refactored out. That's great. Not sure if it's worth several in the stable and experimental. But yeah, it hasn't been too much of an issue plugins. Yeah, you're possibly a page will be useful and putting the dark either in the dark theme repo or Jenkins for theming. Yeah, I think dark theme could be a good starting point. But technically, we can edit to developer guidelines because it applies to anything. For example, if we update now to seem to CSS variables will be exactly the same keys. You already have a theme management for users. So we could create theme development best practices page in the plugin developer guidelines. And after that, yeah, we can create a blog post or whatever to just highlight that or maybe developer meetup. I'm not sure. Yeah, but that would make that would make it sort of official. That will sort of be a sort of officially support themes. Well, you already documented themes support policy on the Jenkins interface with disclaimer so that we don't guarantee compatibility, etc. Yeah, sorry, what I say is that you would officially show an API. I think if I don't know for me it would feel as long as you publish an API and you document an API, it changes everything right in the flexibility you will have to iterate and everything. I'm not saying it's valid. I'm saying it should be done with care. Well, we can avoid the document in KPA. We can document best practices. So for example, if you develop a new theme use Jenkins version or whatever plus you see CSS variables, support, but fall back so that Internet Explorer compatibility is retained. So something like that. Sounds like a great idea. And providing the dark theme as a reference implementation that if you want to follow example, the look at dark theme. Yeah. Okay, yeah, you I think you're right. You do make a great point. I think maybe. Okay. Maybe we're gonna see this recommendations. We have updated the info at least for maybe things should be updated every LTS. At least maybe things should be. Make that. Yeah. Let me let me write it down. Okay. Yeah. Anything else somebody anybody wants to talk about. I've got dark theme working with each hearts and the bootstrap plugin. When I see you. Would you would you share your screen with it? No. So this one is the bootstrap plugin with warnings in J. So signal that but So this is the warnings. This is running the warnings in G build. It's not perfect but I spent quite a while getting it reasonable. I overrode some of the bootstrap size stars with the Jenkins variables. So there's already a Jenkins style which makes it look better on Jenkins. So you see some of the problems that the CloudBees Jenkins health advisor plugin has. The bootstrap API plugin doesn't have it because it's got this file which makes everything fit in a bit better. So basically the section here just resets some of the bootstrap styles back to Jenkins styles. Yeah. Yeah. About the CloudBees health advisor. I mean, it's I think it's a completely different thing because it uses bootstrap just to show alerts. It's going to be fixed as a bump baseline. This is a much more complex case. Definitely. I think I will try to look into this plugin something I've been wanting to do for quite a while is looking into the bootstrap plugin. And for example, for me, it makes no sense in well, it would make little sense to. Let me phrase it would be better in my opinion. To that the version of bootstrap that ship that the bootstrap for API plug-in ships. Do it does not contain a typography resets and basic style resets and everything. It just includes, for example, table widgets. You think it would scarves anything to everything else. But yes, they shouldn't override the typography of the page, for example. And that's something I think can be done to modularly load the CSS file. So that's something I wanted to look into the future and that would reduce the need for you to work on. For example, the body, then the changes to the body tag. You shouldn't need to do it. Yeah. Because the plugin will always run within Jenkins. And Jenkins will always provide. We know Jenkins will provide a set of base styles. Yeah. I didn't have a lot of pressure just dropping it back and seeing what was in use. But there were quite a lot of things in use just around the table. It's another icon out of it. I don't know if I probably wouldn't have time to do that full strip back. No, no. You should do it. I think it's great. Yeah, I think it's. Yeah. Yeah. Yeah, it looks great, actually. Did you, were you able to try it on Internet Explorer 11? I could if it though. I haven't currently.  She's getting good with that. Yeah. Yeah. Yeah. Yeah. Yeah, yeah. There we go. Uh, So it's an X for Aliva and should just look like what it looked like before, so none of these styles should get applied. Yeah. This is just so anything that's not missing should fall back to what's certain bootstrap. The other one is the e-charts plugin, so this is, I've only done the trend chart so far, but this is like the JUnit plugin, and then these are the warning and warning into G charts. The only thing I've set is the text color. Without these changes, the text color was two faders. I think it looks great, but that's my opinion. Literally, it's just this line here, it pulls the text color and then pulls back to this, if it's not available, and I've tested it on old versions of Jenkins and it works fine. Yeah, I love the way CSS is run, the way that you can access CSS variables from JavaScript. Yeah, the hardest bit is just the e-charts documentation is very, very, very extensive, and it's very hard to find what you want. It's like API documentation, but it's not very user-friendly, put it that way. I found the right variables in the end. Mm-hmm. Okay. Those have all got core requests open, and so that's the JUnit one. The latest state of the JUnit one is the top one, which I showed last time. Looks great. I think it's a nice approach. I'm wondering, Uli, were you able to work with the new color palette in Java as well? Yes, I tried it. I posted some pictures, but I didn't find much time this week. I thought it would make more sense to have it some kind of toggle, so you can simply switch it in the user interface. Otherwise, it's a little bit hard to change and look at it and change and look at it. I thought it would make sense to make it simpler to configure, because the current colors are a little bit, let's say, I don't find the right English word there so hard, and the old colors are some more smooth and some not so... Yeah, I understand what you say. And the same is, maybe it's comparable to your new tables. The new tables with this black, everything black, it's very hard if you look at it the first time. And if you look at tables in GitHub, for instance, you just have these small lines, and now we have these hard blocks everywhere, and the same is for this color palette. So I think the colors should be a little bit more not smooth, it's a little bit lighter. Or how do you say it? Warmer, maybe? Yeah, warmer. Or softer? Yeah, softer is better. Yeah, softer. But I think I'll try to find a way to make them configurable. Then it's maybe easier to click in the UI and then change a slider, and then you see how the colors will change. It's easier to see, I think, rather than compiling and deploying, and then you see the new colors, and then you can't compare to the old colors. So... Yeah, you should be able to hotswap that. Yeah. Yeah, it's a bit annoying that those colors don't change live when you change CSS or anything. Yeah, currently it's in Java, the colors, but maybe I think there is a way to replace them in the in the JavaScript part. Yeah, possibly there could be CSS variables as well. Yeah. Mm-hmm. That would be much simpler. Doge charts has a theming capability included, so you can change the colors of the charts using a different theme, but I'm not sure how this would work with our theming concept. I'm not sure if that works, that we can use Jenkins themes to style the charts, because I think for the black theme, you need a different color for all these things, otherwise it looks a little bit weird. Sure, that's something we can do. Probably we can use them. We have a wrapper for the each charts API, right? I think we can use the CSS variables there, probably. But I don't know. I haven't looked into it. Uli, may I share my screen for a second? So is what you were saying something like this? Pardon? I don't know. What are you asking? The table color, I mean the table heading color, something more... Yeah, I'm still thinking all modern UIs don't use a background color, they just use lines to style tables and tabs, like the calendar and my tab. This is just a line and no color. You have a look at GitHub, when they use... I think the color is so... Yeah, it's so highlighting everything, but the table header is not the interesting thing, the table is the interesting thing. Yeah, here they use lighter gray. Yeah, and if you look at the tabs, for instance, in GitHub... Yeah, they use... Yeah, they have different tabs. Can you click at code? I think in code you see some tabs inside. No. I think it's in issues maybe or in pull requests? Yeah, this... No. I don't know. To be honest, I'm not informed. Sorry, can you open one pull request? Just... Okay, I'm dark theme plugin. You're one of the closest ones, it does not matter. Just... Here's... Just open it and here you have these tabs. And these are the typical modern tabs, I say, where you just have one line which shows the surrounding. The same is in Bootstrap, they also use just a line. And I think this using a background for all these tabs is so hard, somehow it takes the focus off with the eyes. And I'm not sure if it's so good. So in GitHub you see it's everything is so kind of light and soft. And using a background color for the tabs is somehow... And the problem I found is that, for example, tabs in Jenkins, these are great if the tabs are standalone and just section everything underneath them. But here in Jenkins we have tabs attached to tables. That's actually what it's... Yeah, I know. So maybe we can add a top variant. It's easy enough to create a top variant color. I actually quite like the way it looks, I mean, just to be contrary. I mean, I think... Yeah, maybe she just... It's my issue with it. Just looking at that screen, my focus goes straight to that header. Yeah, because I think it's because this header isn't a primary color. I think it's... I very much prefer this. I think using this in this way, I think the header is neutral enough in the color of the top. It's definitely less eye grabbing, but it still does draw you there. Would you prefer to go with a gray like this one, for example? I prefer this color to the one you had up before. What if it wasn't... What if it was no color, though? No color. Yeah, I can... Let me sketch something out tomorrow, okay? I'll see what I can do. It's going to... It's not... Let me give it a try, okay? So under you are actually... Can you have any insight of the current to design trends regarding this element or of colors or anything? I don't have any preference in terms of color. I think that I feel like generally speaking, having tabs, you really only need the border to make it feel like it's all included, and then the table can be a separate element. When it's like a combined tab and table, it's difficult because you're trying to make the header the same color as the tab. But if you just move the table into the tab section, it might be easier to understand. Header into the tab section. So you need to find it in the tabs on the headers. Yeah, like separate the table, like move it down into the tab, so the tab is just like a container. Yeah, okay. Yeah, I see what you mean. Actually... I think you need to understand. Otherwise, instead of a tab, maybe it's like a toggle? I don't know. Yeah, I think this is a good case because it's only present maybe here and in another place. And the problem with these tabs is that it was sort of... I recall seeing... I was doing some research yesterday or today to see where this was implemented. Only, I think there was a piece of feedback from you that argued in favor of putting together the tabs and table and removing separation. The problem with putting an underline, by the way, is that it looks really weird having a different color line between the tabs on the header. Yeah, I don't think that you need necessarily to make a border underneath the tab. Just maybe if you considered the tab as sort of like file folders, what they're kind of modeled after, and then the table is inside of it instead of putting tabs onto the table. Mm-hmm. It might just make more sense as a container, but other than that, I mean, this works. I think it does just fine. It just sort of is like putting two different mental models together, right? Yeah, so what we did is try to work within the framework we had. If we want to go on a more radical... So, yeah, I found out this PR. Wait a second. So, there was an existing PR a while ago, six years ago, basically, that created this. The first thing was this. I found this earlier today. So, in chain, well, we can follow this discussion. I will put it on the minutes. So, basically, it eventually became this on this discussion. So, do we want to reopen this discussion? I'm asking, yeah. Yeah, you can also have a look at the tables from the warnings plugin. For instance, they use quite a softer model. So, the tabs and the tables. And, typically, in tables, you also have a search and a filter and things like that, which are currently not used in Jenkins, but they can be used. So, yeah, okay. Wait a second. Okay, we're over at the time. I don't want to delay this any further. Yeah, so, you're using this? Yeah, yeah, exactly. Like this, right? The tables in the tab, instead of being part of the tab. I, let me say that I very much prefer this one. Also, we just started to work within the framework we have. What I suggest is let me try to come up with some alternative heading colors with maybe a black, sorry, a full white heading background. And let's validate it. Maybe I will share a few screenshots tomorrow on the PR as part of the discussion. I will ping you, Uli and Tim. And, yeah, we iterate. Nothing stops us from shipping something now and working it next print. Yeah, absolutely. Because what I'm afraid of is that we have, I think, I don't want to delay any meaningful improvements of tables for the next LDS or something that we can just iterate. Sure. So, do you agree with this approach, Uli? Yeah, that's good. Okay, great. Yeah, and we're over the time. Thank you, everybody. I think this has been a great meeting. See you in two weeks. Okay. Awesome. Thank you. Thank you. Bye. Bye.


So Sony have recently announced that the PSVR headset has sold over five million headsets worldwide But I've noticed that people out there are interpreting this information in different ways So it might be kind of confusing to know whether or not like five million headsets is that good is that bad So what I'm gonna do is I'm gonna try and interpret this information in my own way And I'm gonna try and explain my reasoning. I'm gonna try and put the PSVR sales into context Okay, so the crux of the issue here that I'm noses in any way is that the comparisons that people are making so for example The ps4 has sold through 106 million units So the people are putting the five million that the ps viewer has sold They're comparing it to that number and when you compare it to 106 million obviously it looks really really low Another one I see is with Microsoft's Xbox connect over on the Xbox 360 back in those days That one sold 35 million units and again you compare that with the five million of the ps viewer And yes, the five million looks low again But I think both of those comparisons should never be met in the first place and I will explain why so I believe that the PS viewer is a platform and not necessarily a peripheral Even though it does take all the boxes of what a peripheral device is and I do recognize that too And what further makes this all so much more difficult is that the ps viewer is part of the first generation of viewer headsets Therefore, nobody has anything else to compare to right? So they're they're going to these other things to try and try and make sense of these numbers And this is why we're seeing comparisons to ps4 comparisons to connect stuff like that So why do I think that the ps viewer is a platform rather than a peripheral? Well, I have a few reasons so my first reason is that it has its own games that can only be played on the ps VR so this at least differentiates it from the ps4 So the certain games for example firewall astro bot whatever you can't just play these on a ps4 You need that ps viewer headset, but you might be thinking what about the connect the connect has own games That could only be played with the connect and not just 360 only that springs me to reason number two ps viewer headset cost the price of a new platform So the ps viewer initially sold for three ninety nine dollars euros whatever and that is the exact same price that the ps4 Launched that it's the same price that the ps4 pro launched us whereas the connect then for example launched at $150 which is much more affordable, and that's the same price that Microsoft are selling their Xbox elite controllers right now Now I understand that a price points aren't exactly Scientifically backing up the point. I'm trying to make but it is something to consider 399 is the kind of money you consider putting down on a platform not necessarily a peripheral reason number three is that the ps viewer has It's own peripherals so what I'm talking about the move controller the aimed 3d rudder these things that you need to play certain PS viewer games now I understand you have a point there with the move controllers So move controller initially launched with ps3 and yes the ps4 does support us and even dreams the flat game does support the Move controllers But Sony have certainly started moving away from using moves in flat games And they're kind of just being exclusively used in ps viewer titles So for example even dreams for example is going to get ps4 support So that will be a ps4 game and then you have the aim controller and the 3d rudder these things are only going to be used with PS viewer not to mention the PlayStation camera is also needed for tracking on the ps viewer and the camera is another peripheral That's that's much more in line with the connect comparison if you ask me than the ps viewer itself So I mean how often do we see a peripheral then needs like multiple other peripherals or at least uses multiple other Peripherals in order to function not very often. I don't think but that's not my last reason now My reason number four my last reason is the Oculus Quest So the Oculus Quest released recently on well, it's not even on anything. That's the point Okay, so the Oculus Quest is not tethered to a PC like the Rift and the Vive and that kind of stuff. It is truly its own platform I don't think anyone can deny that it runs by itself No wires no PC needed and why does that mean that the ps viewer is also its own platform? Well, because the ps viewer is in direct competition with the quest. So as the saying goes birds of a feather Compete together, you know, therefore if the quest is its own platform and it's competing with the ps viewer That surely ps viewers its own platform too So there's my argument anyway of why the ps viewer should be considered its own platform rather than just a peripheral device And I realize that many of my reasons are full of holds but Hopefully when you put those reasons together, it strengthens the whole argument as a whole So now that I've convinced you all that the ps viewer is a platform and not just a peripheral Let's take a look at that five million figure again. It is the first generation of viewer headset It's part of the first generation of viewer headsets It has hit five million before any other headset has done so and it has done all this in americas That hasn't quite breached mainstream just yet. So, yeah I think five million is a pretty impressive number for the ps viewer to have hit in that context now You can look at how quickly sony met it from four million to five million compared to three million to four million You might say to yourself, okay sales have slowed down significantly And that's definitely an argument that could be had this discussion for another day Maybe but the point of this video is to you know Let's not cheapen the milestones that the ps viewer is hitting by comparing it to these other things That it shouldn't be compared to in the first place. Anyway, that's it for this video lads and ladies I'm sure a few people out there will disagree with what I'm saying If so, let me know all about it in the comments below. I'd be happy to hear and before I end the video Let me give a thanks to my patreon supporters whose names are on the screen right now. Thank you very much lads I do appreciate us. Let me give a special shout out to columbus thomas the third pete hawkins tradition and Crumb these boys are supporting me on the top tier over on patreon And I appreciate that very much if you want to help out in patreon too link will be in the description below But if you don't want to do any of that yet, just the usual like You know sharing all that kind of usual shite would help me out big time too and I appreciate that very much Finally, if you're enjoying the music that you're listening to in the background of these videos Then check out to septicom.com for more of that goodness. That is it for this video. I'll see you in the next one. Bye for now


Your web developer wondering what a reasonable JavaScript bundle size is.  Perhaps you're on a web standards committee and you're surveying how an API is used in the wild. Where do you go to find answers to big questions about the web? In this episode we're looking at the HD2B archive and how you can use it to learn more about the state of the web. You can think of the HD2B archive as a data center full of machines continuously testing hundreds of thousands of the most popular websites and recording everything there is to know about them. From how many bytes of JavaScript were loaded, how long it took to download them, if any images could have been optimized and much, much more. As you can imagine with this much data we can learn some pretty amazing things about the web. So how do we start making sense of it? HD2Barchive.org is the place to go for web stats and trends at your fingertips. Common questions about the web like the size of the typical web page or HD2Bs adoption are all answered here. You can even go through seven years of historical data to see how the web has evolved and where the trends are taking us. As a community of web developers this kind of data is crucial to know if we need any sort of course correction or get confirmation that we are in fact heading in the right direction. And this is actually a really good time to be using the HD2B archive because there's a new version being released in early 2018 with an upgraded UI and lots more modern metrics. But what if the stats you're interested in are so specific that it's not available on the website? This is where BigQuery comes in. The HD2B archive data is like an iceberg with a hand-picked set of interesting metrics exposed on the website but so much more to be explored beneath the surface. On BigQuery you could mine terabytes of raw data using simple SQL queries. So let's dive in and see what kind of insights we can extract. The summary pages data set contains high-level data for each crawl. Many of the stats surfaced on the website come directly from here. We can go deeper into the raw lighthouse results to learn more about the progressiveness of the web. For example, we can query for how many websites pass or fail the audit that checks whether a service worker is installed. According to the data about 2,400, 0.6% of the sites tested actually have one. When we compare this to the available historical data, there's a clear increasing trend. Let's look into another hot topic on the web, which is the use of cryptocurrency mining JavaScript. Since every request is logged by HD2B archive, we can query for patterns like whether the URL includes a known mining library. Of course, there are ways to conceal it from the URL and there could be false positives, but this gives us a rough idea. Things really heat up when we start exploring the particular websites that include such code. For example, what will we find if we limit our search to .gov or .edu websites? So those are just a few examples of the power of the HD2B archive. It's a super useful tool for learning about how the web is built. In the upcoming episodes, HD2B archive data will form the basis of many more of our insights. Also, be sure to check out discuss.hdtbarchive.org where people get SQL help, share interesting analysis, and stay afloat with the latest changes. Thanks for watching. .


Happy Friday trade hackers today is Friday, June 14th, 2019. Welcome to this week's video update where we review all of our trades and positions for the week. And before we do that, let's jump into the community and talk about who got caught being hot each week. We'd like to recognize one member of the community for helping other traders continue to be blown away by just the giving that's going on in our community. So keep up the great work, a lot of value being just provided, trade ideas, experience, trading knowledge, so awesome stuff. This week's winner is Jim W. So congratulate Jim, congrats Jim, you got caught being hot. All right, so let's jump into the alerts for the week. And before I do that, let me just go to the platform real quick and take a look. Here's the S&P 500.  If I were just to look at this, you know, I would think that we're gonna look at a continuation to the upside. Now, does that mean we sell out all of our positions and get long? No, we're still slightly short. We're pretty close to Delta neutral. We've got a little bit more short Delta versus our Theta. So we are slightly short. We did add a long position in Netflix today, which I'll go over, but just want to give you kind of my thoughts just on looking at the market and where we're potentially headed.  So we let the probabilities play out and that's what we're gonna do. So jumping into the alerts, let's take a look here starting with Monday, which was the 10th. The first trade was a rolling adjusting trade in John Deere. So we rolled our long put vertical from June, which had 11 days to expiration out to July. And we wanted to just extend duration on this trade. If we take a look at DE, John Deere, we recently put this on how this big push move down and then after earnings even more and then it started to climb back up, we were looking for a continuation to the downside. Now it did keep on rallying, but still we wanted to keep that short delta exposure in that and still got a chance to roll over here. So we'll see what happens, but just extended duration by rolling that trade out. So if we take a look on the analyze tab, you can see it's moved up slightly more after our roll, still within the range here. So just looking for some downside to benefit that trade. Next trade, closing adjusting trade in IWM. So we closed out our short put vertical in IWM, had 11 days to expiration, booked a profit on that June piece of our iron condor. And we're still holding our other full iron condor in IWM. And so you can see prices hanging out right here. So it could use us a little bit of downside and just some more time to pass in IWM. Next trade closing trade in QCOM, Qualcomm. We had a short strangle booked over 35% of max profit in Qualcomm. So we are out of that trade, had a closing adjusting trade in FXI. So we closed out our short put vertical and booked a nice profit on that June piece. And then we're still holding our full iron condor in July. So if we go to FXI, you can see we've got that right here. So we've got a little bit of profit on this one, just waiting for some more theta two decay in our favor. Next trade was an opening trade in GS, which is Goldman Sachs. We did this just to add some more short delta. And we liked kind of the setup in Goldman Sachs. And so targeting over 30% of max profit. This is a bearish trade, add short delta, kind of like I was saying in DE. We got that kind of a push down and then a little bit of a bounce higher looking for that to roll over. It has a little bit, just not quite enough to book that profit. We're up about $260 on the trade, looking for a little bit more downside before we book profits in Goldman. So hopefully early next week, if we get just a small push down, we will book profits there. Next trade, opening adjusting trade in DIA. So we had an iron condor on and we went ahead and added another one. Price was hanging out near the upper end of our range of our first one. So we just kind of spread out our break evens, collect some more credit on our DIA position. So here's the one that we just added. You can see price is pretty centered. Got a tiny bit of profit there. And then our other one that we already had on is this one here where you can see price is hanging out in the upper end of the range. If price continues higher, we will close out the untested side just as we teach in the course and continue to manage that as needed. So that's where we're at in DIA. Both of these are in July with 35 days to expiration. So a lot of time left in that trade. Next trade, closing adjusting trade in ZW. So price moved higher in wheat and so we closed out our iron condor in August that 44 days to expiration. Booked over 30% of max profit on that piece of the trade and then we're still holding a short call vertical in July. We did go ahead and add another iron condor a couple days later, actually this morning on Friday. So I'll get to that in just a second. In fact, that's right here. So we went from 612 to 614 on Thursday the 13th. We did not have any trade alerts. So that's why there is that space there. So we added that additional iron condor back in wheat. And so here's the short call vertical and we've only got, what is it, seven days? Yeah, seven days. So next week, we could look to either roll this or close it. I don't have a strong inclination or want a directional bias necessarily in wheat. So we'll probably just close this. Hopefully we get a little bit of a downside move in wheat early next week before we do so. We'll probably just close that piece, take a loss on that one. And then we've added this new iron condor, which you can see is pretty centered here. So just gonna play the waiting game on that one. Next trade is an opening trade in Netflix. So we actually added some long delta in Netflix. And like I said, I don't mind being a little less short here, just based on kind of where the market is. We're targeting at least 30% of max profit on this one. I was kind of looking at this as a pre-earnings long call. We ended up doing the long call vertical instead just because Netflix is a bit of a higher price stock. And we also get that positive theta component on a vertical higher probability of success. And so that's what we did in Netflix. So let's take a look at that. And you can see there, just looking for some upside in Netflix to benefit that. If we take a look at the chart, you can see it's been kind of bouncing around and we're kind of in that lower end of the range potentially. And so if we can get a little bit of a push higher, that'll bode well for our Netflix trade. And then lastly, a little light on alerts this week and last week, just kind of waiting for something to happen potentially, hopefully a little bit of a down move to give us some higher implied volatility, but just kind of continue to manage. But less alerts, a couple of weeks ago, we had a lot of alerts last week was a little light. This week was a little bit light, but that's just the name of the game. You got to just kind of play the cards that you're dealt. And in this one, we went ahead and rolled our short call vertical and IYR had just seven days to expiration. So we rolled that out to July with 35. And the other thing is IYR goes ex-dividend on Monday. So we were at risk of assignment. So instead of dealing with that, we just decided to roll out. Now we did roll out for a small debit, but that's just because we wanted to keep that short delta exposure and extend duration on that trade. I like having this short delta exposure specifically in IYR. Look here, it's very, it's somewhat, it's fairly uncorrelated to the market. Sometimes you'll see the market go up and IYR going down. So I like having that kind of uncorrelated exposure. And so that's where this is here. Now we rolled this to a point where it's essentially kind of a 50-50 shot from a probability standpoint, but I didn't want to bring these strikes any higher because that would have created a larger debit on the roll. So just kind of kept that debit small on the roll and just hoping for some more downside in IYR. Now we've got another piece to this trade. And unfortunately, these are, I should have varied the number of, a lot of times I'll vary the number of contracts just to keep it straight in our platform. So you just gotta remember, our short call vertical is the 88.92. And if we want to look at the other one, we just check off those and check on the others. And so we've got this other iron condor, kind of a tight iron condor, almost an iron butterfly where price is sitting dead centered, got a little bit of profit, just waiting for some more before I take that off. So that is all the alerts. Let's take a look at some of the other positions, starting with oil. We've got this short strangle in oil. Price has been kind of, as soon as we put this on, price really shot down to the downside and implied volatility spiked up. So we've been down on this trade since basically after day one, since day two, but it's kind of hung around. We've gotten back some of that. We were down about $1,200 right out of the gate, but price was still well within range. And so again, you gotta let the probabilities play out and that's what we're doing. So we're down a lot less on this trade. If we could get a little bit more up movement in oil, some more contraction in implied volatility, we will be fine there. ES, we've got this long put vertical that we're holding for that short delta exposure. Price is slightly out of range here, just looking for a little bit of downside movement to get back into range. Gold, we've got an iron counter, it's been awhile since we've had a gold position on, but implied volatility spiked up. Sold some premium, up a little bit of money, not enough to take off yet, just playing the waiting game there. Nice move up in our favor in that gas today, up over 2.7% at this point. So we need some higher prices in that gas. Get us back closer to center. If we can get between kind of that 2.5, 2.6 range, that would be excellent. We take a look at that gas. It's just been kind of on a slide since March of this year. So just looking for a little bit of cyclicality, a little bit of two-sided action. If we can get a little bounce up here, that would bode very well for our position there. Bonds have been really strong. We've got a short strangle, which we adjusted into a straddle. And so prices just kind of hanging out in the upper end of the range here on bonds. If we take a look at just our put side, our untested side, you can see still got a decent amount of premium in those options. So not looking to adjust yet. If price does continue strong to the upside, then we'll just roll those puts up just like we do. Got a lot of time left here, 42 days to expiration. So not looking to roll out in time, just looking to manage this as needed. Of course, if we come back into range, we will be able to book a nice profit in bonds. I mentioned wheat, I haven't mentioned apple. So apple we have on this long put vertical. We put this on for some short delta exposure. Prices come up out of range. So just looking for a little bit of downside to get back in. I mentioned DE, I mentioned DIA. EWW, the Mexican ETF, we've got a short strangle on. We've got some profit here, not quite enough to take off. If we get a little bit of downside into next week, we should be able to book a nice profit on that one. Intel, I actually just recorded a video on this because this is something that we come across every once in a while when we go inverted on a strangle. But the, so that video will be coming out on the blog next week to kind of discuss this as a scenario, but basically we're inverted on this trade. We're still down a little bit overall after adjustments. Even though we're at over 50% of max profit as we stand after the roll here, we've got, how much time do we have? We've got 35 days to expiration. So we're not looking to roll out to August necessarily yet. Now getting into next in the next week or so, the August cycle will be under 60 days to expiration. So even though the July isn't even close to 21, we may look to roll out to August, extend duration, lock in kind of the credit that we've gotten on this piece and continue to manage and look for some more theta decay. As far as the earnings go, earnings aren't until around July 25th. So we've got some time to still get some more theta decay before earnings. And then we can make a decision as we get closer. You know, if we've got a little bit of profit, even if we haven't booked our initial target amount of profit on the trade, if we're up anything on the trade, we'll probably just close it out and take that profit. If we are down a little bit, we may consider holding through earnings, but we've got some time before we need to make that decision. Next trade, I mentioned IWM, IYR, KRE. So we've got a, we had a short strangle on here, rolled that into a straddle and got some profit since that roll. We're still down, I think it was about $100, $200 on the trade. So just waiting for some more time to pass, some more theta, two decay in KRE. I mentioned Netflix, QQQ. We've got two sets of short call verticals. Price has been strong to the upsides. So looking for some downside to get back into range on the Qs. SMH, we've got two different pieces on. This is our adjusted strangle. You can see we could use a little bit of upside movement to get back to center on that piece. And then this piece here is an unadjusted short strangle where we've got some profit, but not quite enough to take off yet. So waiting in SMH. SPY, we've got two pieces here. We've got this full iron condor. We've got some profit on that piece, waiting for some more before we take anything off there. And then we've got this short call vertical, which is from our previous iron condor. Price is just out of range. So looking for price to come back down on that piece before we do anything. And then XLK, we've got a long put vertical here. Just looking for price to come back down into range there as well. And XRT, we've got a short strangle where we've got some profit. And if we get a little bit of down movement, a little bit more time to pass, we should be able to book a nice profit on XRT. So those are all the trades. Those are all the positions. Everybody have a great weekend, and we'll see you next week.