YUI Library Open RoundTable, 17 Oct 2013

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: YUI Open Roundtable Oct 17, 2013

Description

YUI Open Roundtable Oct 17, 2013

A

Welcome to the next yy open round table. It is thursday october 17th 2013., I'm here with derek catherine, hello and everybody on the internet who is willing to listen or watch, including the folks on the yui channel.

A

um We were going to talk about uh pure css with uh eric and tilo what they were called away last minute for important stuff. um We have a pretty much open schedule today. I have a few things to talk about regarding uh yy conf that I can share and derek has some things to show as well.

A

We basically um right now in terms of the things that are going on with the team. Everyone is getting sort of ready for uh yy comp. People who are speakers are starting to work on that. Their conference talks next week, starting monday, we'll be having um time blocks set aside for anyone who wants to who's. The speaker, who wants to do dry, runs for their talks with us on the team.

A

So if you're a speaker- and you want to practice your talks with an audience, we can set up a open, hangout, open, uh google, hangout or, however way you want. You can even come on campus, if you like, later on today, pending just getting basically doing editorials on it. There's going to be a survey like we did last year of all the yy talks, so you'll be able to vote on the ones you like the best and that will go from today through monday. So we are crowd.

B

Sourcing the talk selection.

A

Yes, just to see like which ones seem to be the most popular, so we can make sure that those are let's get the most attention cool, so that's cool stuff. um I believe we did that last year, too, right yeah, roughly around the same time, minus a week so yeah it would have been last year, was like the 23rd or something so are.

C

A

Talk, I will be talking at the beginning, I think of the um last year we had the. uh What was that? Let me see here it.

D

A

Sort of open talk that we had the town hall meeting style.

E

Oh yeah, that's right.

A

So what I'll I'm going to do is give kind of like a retrospective on what what has happened this past year, there's been a lot that has changed this last.

C

A

Things like the new branching strategy, removing stuff left and right cutting.

C

Out stuff yeah, just overall openness of the project too,.

A

Yeah we'll be covering.

C

A

Like, uh like, I said, like brian's branching strategy, uh we have like a lot of that performance improvements going in edits, the editor stuff.

B

A

Let's see just checking messages um so yeah, it's gonna, be cool, so I'll be like doing a short intro for that cool. um There's some other cool things going on with wyatt conf. Once we get the schedule out we can share um and that I know that I can share you, but there's there's also something really cool. That's happening um near the end of the day. On the second day.

E

A

Really really cool that would be totally worth it for you to come. Even if you didn't come to anything else and again, I wish I could share that, but if you're out there and you've already signed up for the conference, please share this with other people, the registration or, if you haven't registered, please do so as soon as you can, because um the the early bird pricing ends out next week. I believe is that right, yeah, that's right!

A

17Th, yeah! Okay! So that's it for wildlife comp for now. um What's.

C

Derek got on this um yeah, so one of the things that we've been working on, uh or at least heavily investing resources into, is ci, making sure that all of the code commits that come in, uh don't actually break any code and yeah. It's just good to have a stable code base that we're uh that we're all developing on top of. So um as we do testing in ci across. Oh, I don't know how many browsers do we or how many testing environments do. We have probably like a dozen.

D

C

Yeah um doing all of that testing every single time somebody pushes code takes a long time, um so one of the ways that we are working on making it more efficient is actually only testing things that need to be tested.

C

Well, the the immediate problem with um I guess, if you look only at the in in the context of yui the problem with only testing code changes, is that uh or at least the the files and modules that have changed is that you have issues downstream, because you could pass all the tests in widget, but um widget might not be testing something that I don't know data table uses, so you might break something in data table. um So you, uh if I.

A

Get dependent on some quirk.

C

Or behavior that before.

A

C

Yeah correct, so um what we're actually doing is one of the projects I've been working on lately is a dependency calculator, so basically, your source is a module that you're working with and or a list of modules that you're working with, and that will do upstream and downstream calculation of um everything that it depends on, as well as what, uh as well as modules that depend on it.

C

So how does there's all those things uh so loader currently does uh upstream dependency calculation uh and that you can find in uh build loader, uh yui 3.json uh file, so there's a json file that has a full list of all the modules and all the dependencies that are included in there. So that's how loader works. uh What we don't currently have and what's applicable to.

C

A project of making testing more efficient is downstream calculations, so um we're in the context of widget, whereas upstream would be like uh I don't know, uh attribute in base and all of those and all of those different uh modules that widget needs to run downstream.

C

On the other hand, is everything that depend on widget, and we don't have anything like that in the library right now or available as part of our developer tools so um yeah, so I can at least give a quick little demo of what that looks like um it's currently not open source yet, but it will be soon. um So let me share my screen.

C

So um there is a let's see here. I should probably bump up the font.

C

Yeah, so at the moment, this tool has a yogi plug-in a command line tool, as well as just a general api that you can use within any.

B

Explain with a yogi plugin yeah, a yogi plug-in is.

C

A plugin that works with yogi.

C

So, since all of our development tools um have some sort of um interaction with yogi um yeah, it made sense to kind of uh add a yogi plug in here. I'm not sure how useful it'll actually be, uh but I don't know- maybe I mean it. It was pretty painless and quick and easy to.

E

Write that verb to the.

C

Yogi's yeah at the moment this is just a separate tool, so it's yogi dash. What did I call it? I don't remember why dc yui dependency calculator, so um yeah yeah, so I won't actually, probably it won't ship with yogi, but you can install it if you would like and so.

A

It would be on npm.

C

That you could uh bring things up, yeah, yep, so um yeah I mean I guess I could just show so. Let's say I'm curious about um button since I've done so much work inside a button, I'm curious. So what is upstream um on button? So it actually lists out the the components and modules so this modules list. This is identical to what you're going to get from loader.

C

Actually, it's not identical to what you're going to get in loader, and this is one of the reasons why we're not using loader for this upstream calculation is because look for example. Here you have dom style ie. If you use loader it's um it's not going to pick up that ie module because you're, not loading you're, not using loader inside of internet explorer, and so voters, um gonna, say hey what environment are we in we're in node.js, and so we have a bunch of node.js modules.

C

So if there's any, um if there's any environment, specific modules go ahead and load those in so um what this upstream calculation actually does now is. It includes ie, um win, js nodejs, all the different modules that we actually have um uh uh ignoring any um environment concerns that you normally get within motor so uh and then just as convenience, I uh broke it out and actually do the list of um applicable components as well. So uh this is useful in the context of uh testing.

C

So, uh but if you scroll down this little tree downstream, um you get button and button, there's no dependency or there's no downstream dependencies for button. um So, but if you do like a button so that button refers to the button widget, if you do button core, then you're actually going to get some. So this is useful for any developers who are working on components that actually are dependencies like uh when I was doing a bunch of recent button core development.

C

I totally forgot that uh panel and widget buttons rely on uh button core, so um those weren't actually being tested. um They were being tested in ci, but as far as me, a developer when I, um when I complete development on the project and say okay, this is done and complete. Now I want to push it up. It hadn't actually been tested in panel yeah. So um but now um I'm much more aware of that. So now this.

A

C

For like gallery components uh yeah, so it it doesn't have any gallery, um it doesn't have anything with gallery now, but it certainly can in the future and um it does support uh yeah. If you look at the when it's open sourced, at least um you can look at the code and it supports custom dependency trees as well, so it doesn't even have to be yui um yui three specific it can be um with whatever type of stuff you're working on. um So how do you build the tree yet?

C

So the tree is built up um just uh by looking up dependencies and then recursively looping through that, so is it is that a yui.

A

Thing or is that a just a javascript thing.

C

Just uh yeah: um how does that something declare dependency on something else? Yeah.

A

C

The use statement I mean, I think it's- I think it's useful to pull up the uh yui three dependencies, so here's uh yui three dot json, uh which is a file within loader that gets put into uh the yui seed at build time. So basically, this file just contains a list of all the modules that are in the library and so here, for example, a line align plug-in requires the following modules.

C

um We also have use. um So when you require an m, it's actually going to pull in those. It's like a rollout. It's a roll-up module. Yes correct! um It's actually going to pull in those um yep and I think there's one other. We have require use and optional.

C

um No. uh What is that?

C

uh Oh con condition? Well so yeah, there's conditions so here, for example, is one uh that is actually um uh triggered when it's in a um let's see.

C

Oh so there's a test that does uh there's a test that will return true or false, and um to look if uh native app transitions are available, so go ahead and include the native module, but it's triggered here. um So um I guess a better one would be yeah, so ie style test. So this script actually contains the test to actually look to see.

C

um Should we include this module or not? You.

D

Know so dom style is the is the when you include dom style. It looks.

C

Yes, yes, that is the trigger module, at least so, when you include dom style, it will run this test and if it uh passes, then it will include dom style id.

C

um And so I thought there was optional yeah optional. There we go um so there's also these that can optionally include different modules, so actually not sure how, when is why is optional? I don't know, I need to look at option award see. I guess what it's why, when those are triggered, um I'm still uh learning a lot of this loader stuff. um It hasn't been one of the uh areas that I've explored in a whole lot. So this is something that.

A

um If someone's creating a new component, they need to modify this file.

C

Well, yeah: this file is actually a rule as a combination of all of the. um So if we look here, yql uh yql, meta yql.json, uh so all of this stuff is actually just basically cut and pasted um by a script at least.

A

D

C

Of them so also.

D

A bigger one, that's.

C

Not uh it's it's computer generated, yes, the bigger one is when you rebuild shifter or sorry. When you rebuild loader with shifter, it will actually go through grab all of the json meta files and uh combine them into one.

A

So so you're, so the thing that marco was talking about something on on the dev channel uh modules. Why do I have modules explorer? Do anything about that.

C

A

Yeah yeah, so the wi-fi.

C

Modules explorer uh that will actually do uh some static analysis of the um of the code yeah, the input code, which is just uh any yui script um and it'll, actually um look up and see which classes uh are used within that are used within that script and then from there look up to see which module provides those classes and then tell you which modules you actually need to include.

C

So it's similar- and I think at some point- there's certainly some convergence um there, but all we're dealing with here is just the uh the module metadata, um whereas white uh the yui modules explorer that actually does a full profile of um all the white. All the code within white.

A

Reverse lookup.

C

A

C

The classes um yeah it looks yeah basically which modules provide, which classes and okay. So it's more like class and method, yeah correct, yeah yeah, um because it's yeah, I can see how they could complement one another yeah, so it just does a full esprima analysis.

C

um So anyways, um let me think here so what yeah we we now have. If we have the ability to do dependency calculation, we now um can start using this in various dev tools, so one that I just started working on a couple days ago and have it mostly working at this point- is in yogi. So um let's go into yui three um source yui, um all right. So now let's go into the one we're looking at before, which was button so button.

C

Let's do yogi test, so this is actually going to do all of uh the test just for button. So this is how we, as you, ai developers, um yeah test our components at least one way that we do it um so. But the thing is when I'm doing development on button, I want to actually run the tests against everything out there. um That actually depends on any of the button components so or button modules.

C

So then, if I throw a downstream flag on here, um that is where it's actually going to go through and not only test button, but also test uploader uh panel and widget buttons, so cool yeah. um You can do upstream too. uh Well, yeah you can test upstream. I mean it's possible that I could add that in here, but uh by doing modifications in button. That would mean I would need to test widget, which means to test base and but there's not really any need to do the upstream tests. um It's only down.

C

It's only testing downstream right, yeah yeah. So if I go into like widget, for example, um let's do yogi text. um I believe this is actually pretty quick yeah, so it's going to do yeah only test for widget base and widget. Now, if I'm doing development inside of widget, that touches a whole lot of components out there. So um if you throw the downstream flag on here,.

E

C

Now it's actually going to test every uh yeah every component that relies on on widget, so charts and calendar and autocomplete and charts, does it cascade? Does it do their downstream children too yeah yep yep so uh or wait? No, it won't do no, because we haven't modified any cut like in charts. For example, we haven't modified any code in charts, so, but what.

A

I mean is, like so say, say: charts depends on like widget right and then something depends on charts.

D

A

You made a change in widget. What, if that affected, that? That component, that depend on on charts, which depend on which.

C

Okay, oh okay, I see what you're saying then. um Let me.

B

Think here so I mean don't you need to do all the downstream.

C

Yeah yeah yeah yeah, so it actually does uh all that testing. So um well here, let's actually double check here. So um are we getting we're getting button tests? um We have widget buttons. Do we have panel, I mean, but yeah panel is already a widget, so I don't know I'll look into that to double check, but.

C

The dependencies of the dependencies of the dependencies so yeah yeah, I mean seriously so it seems like if you did base right. You should do a ton of things, yeah yeah yeah yeah, so we do like uh ydc yui base. That's what I mean. That's pretty much the entire library so.

A

That's my question is: if, if something is like two children down, is it considered a downstream dependency on that like on widget? Would widget know that all of its children's dependencies are also downstream or is.

C

It only go one.

A

One leaf down, um so I'm trying to so like if you did base on this.

E

On downstream on base, like.

A

You so you're saying like charts right are, I guess, if you look at button right, you're saying that.

D

Panel is downstream from button is that right uh panel is downstream from button correct button core.

C

Yes and this panel on here at all yeah um on this.

A

On this level,.

C

A

Yes, so it's picking it up anyway, but you don't know what the it's just. But you know what.

E

I'm saying like.

A

Is it showing up on here because it's a direct dependency on on base, or is it because it's been directed yeah.

C

uh So I mean the indirect dependency, so I mean that's when you go into dependent of dependent up dependent yeah, I mean it. It crawls through everything um so yeah, because it's just using the same the same lookup method, uh recursively right and the in the source. For that, for that method is the module um and then it looks up- and this shows up on here, yeah: let's go that way. You don't accidentally miss something yeah I mean so. The idea is, the idea is to both for developers as well as in ci.

C

Make it is painless and easy to do good quality testing, so when you run yogi test, eventually it's not going to be. You won't have to specify the downstream flag because that will be tested by default. um All downstream stuff will um so right, but when you're doing dab, sometimes you just want to do just that. One yeah.

D

And so then, at that point you.

C

Can actually, you can probably um specify one specific module that you wanna, that you wanna test um so yeah, that's basically uh at least a little preview um of stuff that I'm working on with the downstream dependency calculator. So other ideas for things you could use this for um yeah. You could do a um you could do like uh uh what about they get here, oh uh configurator. So if you go to like yui library.com, slash yeah on the onylibrary.com there's a configurator, um and uh that is browser specific.

C

So this is actually one of the maybe a bug that I that I realized during development of this is because um yeah, if we go to wayward.com oh yeah, you can you can share it again. I guess- um and if I go to um where is that yeah quick start configurator yep? So here's the thing. So if I want to do a I'm trying to think uh okay, so io, so I want to have I o capabilities on the site. So where is I o here? We go. I o roll up. Okay.

C

So then, this is going to tell me all of the modules that I'm going to need for I o. So then, okay, so I go ahead and cut and paste that in and be able to use that problem is uh the script that I just developed, won't work for ie users, uh because um there is the ir. uh Sorry, not not all I.e users, but um it's not going to include the ie sub modules, because.

E

I believe there are some.

C

With uh with io, oh, so you have to like choose that, so you would, if you want something that actually works, cross browser. The configurator doesn't do that, so we're going to probably need to do some work to.

A

So you probably want to do something where you pick instead of having it picked like this, you pick a browser or pick a contact like mobile or something.

C

uh Yeah or you should be able to to specify um environment agnostic, it should actually be a checkbox. So right now we actually do have. This include optional uh modules, which maybe answers my question before of um where the optional flag is used, and it could actually just be in here so yeah so yeah. So like okay, here's here's one! That's already pulled up history hash, let's get rid of the ie roll up, um so history hash. um If you look through this list, it doesn't include history, I.e.

C

You have to include that yourself, um whereas loader would actually um do that environment detection for you, if you're using loader, meaning you're, not using the configurator.

D

A

And yeah, the other scenario I could see like for the for the upstream case was say: you've like ci messes up and you didn't- and maybe you didn't change anything in your component, but it's showing a test error there. You could do the upstream thing to see if anyone changed anything upstream from you yeah themselves that may have potentially broke stuff yeah.

C

Yeah, so I think it's just a it's a new tool that we have um that we haven't had before that kind of opens up a few new doors on things we can do with it, um just in general, with with downstream uh downstream calculation.

A

So so marco says something about. This is great for js code. There's still an issue with broken files, though just found out the gallery. Widget pointer has a 404 for css file, which makes the cdn respond with the 400 error for all combined.

C

C

Yeah yeah that that sucks.

A

I wonder if it's related to other css missing stuff, but the thing is we determined that that's not that's not happening. No.

C

Yeah that issue.

A

C

Of unrelated yeah.

D

C

Yeah note do not uh use github release as your source to.

C

Details on github issue, tracker of a developer grabbing the zip file from the github releases and clicking on the source file button. That is not actually a full release.

A

Yeah, so if you go to any release- and it has it'll say like a source zip, those are not the well they're, not the release files. Those are just a snapshot of the tree on that release. Date. Right, zipped up for you for your convenience, yep.

C

So uh when we eventually get around to removing the build directory, there's still some more development that has to occur to do that, then it won't actually be an issue because there.

D

Won't even be a build directory inside of that zip file for to confuse people. Hey.

E

D

Going to join us potentially, if I can get into the link in time.

C

um So yeah, that's about all I had for the dependency calculation stuff. I guess one. Another thing of note that we have this week is uh the next release um or the next development schedule is. Has.

D

Already been posted so.

C

If you look at the wiki on github, so github.com3 wiki, there's a development schedule link on there, so we began the sprint. Yesterday we are going to get interrupted in this sprint um by you: icon, um hey, tl, okay, hey um and then yeah, then we'll then pretty much. Everybody will resume development and finish up with uh with the final couple weeks before the next stable release is november. 25Th.

A

So there's an idea that most likely will have a beta or something right before you icon yeah. So if you have some code that you want to show for wyoconf- and you want to have it in that in your 3.14, whatever it's going to be go ahead and get that code in sooner rather than later, so that it can show up in the beta, especially if you have something you want to test or try out.

A

But there won't be a release until after yycon.

A

And then also in december, there may be a pause in the releases due to holiday stuff that may go off into the future, a bit more yeah, that's tbd, and we have tilo here. Thank you for coming. Kyla.

A

It's it's, uh I think, whenever you want to schedule something with more than one person, it becomes like this nightmare of, like all the different permutations of these two people can kind of this person can't come, and then these two people are good. I.

E

Know that you guys got.

A

Away at the last minute did.

E

You ever find out what's going on, was it just? uh We were supposed to have this meeting but never materialized. So I'm back here.

A

E

Cool, so um so I do have some stuff to show um and some other stuff to talk about. I don't know where eric is. Let me see if he wants to come.

A

You're, the secret guest now since twitter thinks you're not coming.

E

All right um so I'll show some stuff. I've been working on some stuff in yui land, which I can which I can show, and then I also have some stuff um peer related that we could talk about. Let me just open something up here: make sure that I everything's working.

A

You sound like those hackers on on movies where they're like this is unique. So I know this.

E

All right, okay: here we go.

C

Just got flashbacks to uh hackers, the movie um yeah or.

A

Was it the um was the dinosaur movie at the jurassic park when she said all right right, she's like this is unix. I know this yeah and it starts clicking around with the gui.

E

Okay, here we go um so you guys. Can you guys see my screen.

C

A

Yeah hold on okay, you're inceptionizing right now. There you go.

B

Do you guys hear it.

E

C

Maybe bump I can read it online.

E

Oh yeah, another terminal I can I'll- uh I don't know: okay, there's somebody blocks there, yeah cool, so I've been working on a bunch of event, related changes in yui, um mostly to do with gesture events, and actually this is kind of like similar to what I'll be talking about or ue count. But this is not that pretty and it's still pretty early stages. So I thought I'd just show what I've been working on. um One of the things I've been working on is enhancing the event flick module.

E

So this is actually a pull request right now. uh Basically you can now. um So when you flick, you not only get the flick event, but you also get flick right and then, if you flick left, you get flick, left flick up flick down. So the idea is that.

E

F

Go ahead, I said, I think, there's a plugin you get for the president will show your finger so that when you do demo.

E

Oh, like click events like oh, you know what I'll do I'll just I'll, just I'll just use the um touch mode here which helps a little bit yeah.

E

So I'll just do this now you can you see that a little bit better yeah there you go yeah, so you can kind of um so I just added these um sugar events to the to the flick um events api so that you can actually um so this this dot. This element here is just subscribing to all flick events, flick, flick, right, flick, left, flick up, flick down and then th they'll fire flick, always fires. Then you get other events that fire based on.

E

You know whichever direction you're flicking it, and this works really well uh one of the things that it does well. Is um you it works well with mouse and touch I'll get into that a little bit later um and it doesn't have any like. Oh, I checked the scroll view tests they all passed and everything looks fine downstream from the flick module so yeah, that's something I've been working on, which is cool. Oh look at other things like pinch and zoom, and things like that.

E

Yeah pinch and zoom, I pin pinch pinch. I haven't started working on yet, but the other thing I'll show you that I've been working on. um Let me just change branches here for a second.

E

E

Okay, hopefully this works so yeah it works, so the other thing I've been working on is actually enhancing the event gestures suite. This is also in a pull request right now. um Basically, this makes gestures, um work really well. Well, the whole gesture moves start gesture, move and gesture move, end events. um It works really well on devices which support both mouse and touch, and it also, I also cleaned up a lot of the um the way a lot of the configs are are managed. So let me talk about that one one. At a time.

E

First thing: you'll notice is okay, so, let's just so right now, I'm using the chrome's touch like um simulation tool. So this is actually firing. Like uh touch start touch end right, can you guys see that it says like touch start touch hand here, yeah, yeah yeah, under the hood? What it's actually doing is it's firing, touch, start, touch, touch, start mouse down, touch, move, mouse, move and then touch and mouse up and then a click.

E

So it's firing both touch and mouse um and what event what the gesture module does now is it's it's smart at knowing, okay, this is going to fire another a mouse event after touch event, which I don't want to capture, because I don't want to fire. Just remove start twice.

E

So what it does is actually says: okay, the touchstart has come in I'm going to just no up the mouse. That's coming in after that. So it's not like it's preventing default.

E

It's just doing a no op, so the cool thing about that is okay, so I'm doing like touch start touch, move touch and um it's cool because let's say, if I want to do something on touch start, I can just code it against gesture move start and that will fire immediately on touch start or mouse down and then touch end, similar fire on touch and or mouse.

E

So the cool thing here is that, let's assume that I'm doing stuff on a touch device and then suddenly I wanna I'm on- I want some device that has both touch and mouse support right. So now, suddenly I don't. I don't want to use the touch screen anymore. I want to just use um the mouse. So let's assume I just have a mouse now, so that also like works, as you expect so just kind of switches between one to the other, so that's kind of cool.

E

The other thing um I did was improve support for the config options, so you can actually do it so that um these configs were present within all the time, but they weren't the code. For that I don't what I don't I don't. I don't think it was taking the right path. So here I have gesture move start needs to move 100 pixels um to actually fi your mount. How your your mouse or your finger, needs to move 100 pixels to actually fire an event.

E

So you'll see it doesn't fire right now, but then, if I move, 100 pixels it'll it'll start firing. um This is this is similar, except on on touch devices. This has prevent defaulted to true, so on desktop. You won't notice anything untouched. It'll prevent this page from scrolling.

F

Does that work.

E

Sorry is that hard-coded, the 100 pixels? No, this is configurable, so yeah you can specify a min distance. You can also specify a min time this last one here is not going to fire unless it moves 100, pixels and after two seconds, um so that's configurable and then the other config is the prevent default. You want to prevent default behavior, so so those are like three config options for this stuff, so yeah. I can improve this event a little bit. um The next step is sorry. Go ahead. You have a matrix for all these events.

E

It seems like it'd, be really handy to know that yeah, actually that's the thing I'm working on right now so like this is this kind of this is kind of things I'll I'll be talking about during yuikon, but I'll be talking more about how these events all work together. The next step is to kind of make the flick event rely on this event under the hood and then they'll I'll have a matrix as well all what the different events are and how they work together and kind of like this.

E

Is this fires this which wires this, and this is how it's all abstracted out for you so so yeah, but that's kind of the work I've been doing lately in yui land.

A

And this has all the on before and on after and all that stuff, as well built in.

E

um You know that's a good question. I don't think so, because I think on before and on after is only for um there aren't for dom events. There are only four custom events that have to do with attributes. If I'm correct, I might.

A

E

With this, but I'm not sure I have to check that. I thought it was only for attribute events. Okay,.

F

I thought like.

E

Click events, but I'm not sure, okay, you know what you might be right. I want to check. I have to check that it might. Oh, that's really a good thing for me to check yeah you either you might get it for free or you.

F

Just might want to make sure it's on par.

E

Yeah yeah I'll look into that cool.

C

um So with the, uh let me think, with the first thing that you showed with click click left, oh that basically the the main advantage that I guess we're getting now as developers is to um uh be a little bit more optimal uh about how many events our applications are actually uh firing and so yeah. It will improve performance by firing. Less events as well as you not having to manually, do the uh calculations.

E

That was the main yeah. That was the main thing for me, like I just didn't like doing that, all like going in and doing the calculation and then having like a switch statement that told me what to do based on what calculation. So this just it's just basically sugar, but I think it's useful to have.

C

Yeah, certainly because I was thinking you could just include like direction left or right in uh in the payload for the event, but why even fire the event? If the? If you only want to listen to flick rights, yeah.

A

Yeah exactly and you can write higher level widgets that just listen to that depending and you have to worry about underlying right administration.

D

Yep cool, very good.

E

Pure stuff, should we um oh okay? I can talk a bit about this, but.

C

Yeah- and so do we just want to say that for next week, though,.

E

C

E

Do you, if you feel like there's things you want to like preview?

E

Well eric, and I basically I'll give you like a brief overview of what? What what? What what we're talking we're going to talk about um we're, basically going to talk a bit more about like responsive design and responsive grids in pure, a better way of doing that, and basically eric and I had we had a pretty long discussion this morning. um The the what we decided was right now so we're we don't like the existing responsive grid. Implementation, pure is okay, but it's not the greatest, because it's all it does is just collapse. Everything 100.

E

So we want to take more advantage of media queries and we want to have things that developers can specify media queries at phones at tablets at any other media queries that they want and basically have a more robust, responsive grid. The problem with media queries is that once you write one it, you can't overwrite it right.

E

So, if appear, ships with media queries at let's say 480 pixels for phones and 767 pixels for tablets and for some reason, someone someone gets more android traffic than ios traffic and 480 pixel doesn't do it for them um it. They can't remove anything inside the 480 pixel media query. They have to just completely remove the css. You can't overwrite media queries, so um so we were basically like.

E

I was making the case that initially I was making the case that we should have pure responsive grid, which has some sane defaults for media queries um that people can use and eric was making the case that well, we should actually not have any units in pure any grid units or anything like that in pure at all. It should all be done through tooling and in the end, what we decided was some sort of a hybrid approach where, by default, a pure grid.

E

Css file would not have any media queries in it, but it would have like the generic units. And then you go to the grid builder and you specify the media queries that you want and it will add those to the css. So, at the end of the day, what happens?

E

Is you pull in a pure css like link tag with some version of pure, and then you can specify another css file, which has all the media query support, but the ones that you specifically need and that way we we make sure that you don't get media queries that you don't want, um and so you only get the ones you need and it works better for you.

E

But it's also not like you. Don't get anything.

A

Right yeah, I was, I saw the thread yesterday.

F

About that about, I guess it was yesterday- maybe the day before about how a lot of people really uh depend.

A

On the grids and the units- or you know like when they when they first want to.

F

A

It's kind of like a crutch right. It helps them organize things.

E

Yeah so um yeah. Well, I think we're probably going to keep the units in there, but we're just going to remove pure gr that will go away and instead, we'll just have media queries which you can pull in from the grid builder. So then the idea is that the grid builder actually kind of like it's my fault. I made the grid builder and kind of sucks right now, um so I'm gonna have to spend some time giving some love to the grid builder and kind of really sprucing it up.

E

So it does all the stuff, and I will do that as soon as I finish. Some of this yui work for events, that's cool.

A

E

On on getting pure into yui, um I think eric has a pull request that he sent against yui, um basically through bauer um and and some some npm modules. Sorry, some grunt tasks that he wrote and then releases grunt plug-ins. um So I think uh that's how we'll probably integrate.

A

All right, that's like a release fast right. It's like whenever pure updates you'd run this one time you wouldn't run it every time, just just for the one time when your updates periodically yeah yeah yeah. Is that what we do now for like uh like bootstrap and stuff?

A

Is that what we would do well for that in the future for handling.

E

um Handlebars and things I don't know, if you would do it, I don't know, I don't think I don't. I don't think I will place to answer that um for bootstrap. Well, we don't use it now, but if we did it, wouldn't we wouldn't do something like that, because bootstrap kind of encourages you to update like change stuff in its source through uh you know, through the variables that they prescribe yeah. So you set the variables and you get your own version of bootstrap, that's kind of how bootstrap works. How pure works is don't change.

E

Anything in pure, just pull in pure source, then add some css after right. um There are pros and cons to both approaches. Bootstraps pro and conos.

E

You have one css file, which is bootstrap, which has everything you need and ideally like it's your version of bootstrap, but it's hard to upgrade because you have all this stuff inside that you've modified the source with that's why it's a paint of the update like bootstrap 2 to bootstrap 3., uh whereas with pure it's easy to update, because you don't actually modify pure source files, so it but the con is you have another css file, so we just decided. We just decided on different paths.

E

Hey. I have a question for you. Can you show.

A

Dave's site that he built with pure just as a plug for his stuff.

E

Oh yeah, this is actually yeah sure um I will screen share.

A

Some background, uh you know what he's working on a conference or you know the context of this and I was doing a conference or something developer conference and.

E

Near his house, yes, so um this is so dave. Who is a former bio engineer, he's now overseeing node.js yahoo? um He is hosting, I think, the first tech conference or front end. I don't know it's just friend. It was first tech conference in carbondale illinois, um so he's worked really hard actually with, like the local government and everything to and like to schools, to get this like get like um a place to host this and everything and it's getting good traction.

E

So he made the site using pure actually, and I think it looks really nice. uh He actually used the pricing table layout. So the pricing table layout is.

E

He used this layout, which we have in pure to make um this page, which is which is pretty cool um yeah. No, he said he's. He gave me some good feedback on things that are good and things that are not so good and normally like. I knew about the things that are not so good like the menu like he didn't like the menu that much and we are revamping the menu very soon um but yeah. Apart from that, I I think it looks good and it he took.

E

He just took the stores and stuff from here and then and then switched out some css and it worked well so yeah. So you can check this out. It's hack s, I dot me.

F

That's awesome and if you're anywhere in the tri-state area, you're in that area,.

E

F

It's november, 2nd.

E

So you still have some time and um yeah they're pretty active on twitter, so you can check that out.

A

F

Well, let's see, did you have anything else you wanted to share this week? Oh nope, that's pretty much! All I had.

C

Okay, yeah, I just thought of something um one thing that I uh let me share my screen again. um ah It just kicked me off, but it's reloading.

F

You can return right.

C

Yeah, I think yeah this is taking a while reload page. Let's try this again.

C

C

Let me mute, join okay, so share my screen. So one of uh one of the things that.

C

uh Where did go screen desktop so one tool that.

E

C

Across uh recently was called is called pluto p-l-a-t-o. uh Basically, it does uh some some, I think, like jquery and grunt, and some other um some other larger and popular projects use it. uh Basically, it does complexity. Analysis um does some static analysis so like for linting and uh generates basically a full kind of nice. Looking report uh that you can actually look at for your project, so one of them or I ran, I ran it against yui and came up with some.

C

um I think it's some pretty interesting stuff on here um and kind of wanted to share it in case uh things might in case it's useful to run on your own projects as well.

C

So it's really easy to run and you just basically specify the source paths of where all where all your code is and if you have any specific lint options that you want enabled as well. So um basically, what we see here is um for every file in nyui.

C

um The the interesting one, I think, is the maintainability, as well as estimated errors which are um yeah uh the formulas to derive each one is uh at least maintainability is derived from how many different branches um your code actually goes through, um and then the estimated errors, I believe, is um yeah, there's details on here about where they actually came from, but like so the estimated errors comes from um a computer scientist.

C

I can't remember his first name, but his last name is hall state um yeah, and so I think when, when you start seeing your code in this type of form, so what files that high watermark the one? That's like tons of lines of code and high errors.

A

C

B

um Yeah so handlebars is at least one that, uh but.

C

B

Maintainability, a good thing or a bad thing.

C

um I believe, let me look at what some of the other one um uh does. This say: yeah high value means maintainability yeah, so which better why ui handlebars copyright.js, that's 100, maintainability right so more, interestingly, though, is some of the uh some of the lower ones, like so um charts.

C

um What dom selector native, I think, was a low one. Yeah, no dump.js! I don't even know what what the dump component is.

E

The very last one seems to have be pretty low.

C

Oh yeah uh so event simulator is pretty low and the last one is oh yeah yui. That makes sense yeah because that's just doing a ton of sniffing through the browser. So um what's this big one in lines.

B

C

Does it look like grace.

B

C

Oh no, why ui3.js well yeah so um and then jsonp is another one that has a ton of code in it, um but so I mean for some of these here. It's like it might make sense to actually uh revisit the the structure of those files and maybe break it up into smaller components, because when you have, I mean, while granted, yui three dot. Js is a uh compiled file. um I believe yeah, it's not 3 000 lines of human coded stuff. It already is a combination yeah because that's the same, that's the c file.

C

So um but it's like loader.js is one or does that include the. I don't know that might include the meta, uh but so anyways yeah, like the estimated errors. um I don't know if this is like really any kind of actionable item for the forecast.

B

um Yeah lindara seems useful.

C

B

C

Yeah this one seems like certainly I mean this is something that we're that we're going to be working towards, uh probably in the next quarter, uh to actually get all of this stuff reduced. You know what I'd love to see is this.

A

Put against a timeline of the last time the file was touched. Yeah see that you know older code is always more error-prone.

C

A

It's more, you know less lintable. It would be nice to see the.

C

Comparison to that, uh so one of the things, uh so you can get this at github.com es analysis, plato. um So one thing uh let me see if I can find it here so yeah like let's look at jquery's, um so jquery actually does have maintainability um on a graph. So this is all just stuff. That's um run.

C

It looks like once a month um and plato's real uh really easily supports um yeah, uh uh stamping or stamping your report with a date and then any future reports you generate will uh we'll use it so yeah. So does the uh the overtime look at the drop in average lines of code there yeah? So I'm guessing! This is prob, maybe something to do with jake.

C

E

No, but I think they didn't, they recently got amd support.

C

Yeah uh they modularized stuff more. I guess that's at least without a score, because this is average lines of code per file, so yeah yeah, interesting.

A

Oh, I see so even the amount of code didn't change is just the amount of files.

C

A

Yep yep, that's interesting, yeah! That's.

F

Really really cool.

A

Because we, you know the more sort of scientific analysis we do on things like this.

C

A

More you know things will pop up.

C

Yeah- and so I think some of this stuff would be like- I said I don't know that, like looking at estimated errors insane and uh what cartesian charges, there's 17 estimated errors. So we need to get that down to under five estimated errors like. I don't know that that's necessarily an actionable item uh from looking at this report, but what it does say is give the developers of each component a little bit more insight in.

A

And maybe I actually should kind of look at this one.

C

It seems like you could add that to.

A

Code coverage to testing to amount of tests that are.

C

A

You know hunting.

C

A

C

So what I'd love to have is just and I'll probably do it at some point is a um a hash table, basically of all of our paths that we have in the library and with metrics on each one of those that lint errors um and code coverage and uh yeah complexity and estimated errors, and all of this different data uh that we just store snapshots of um in ci. And then we can look and reference all of this stuff. You know.

A

Another context with this would be if you're looking at a pull request and you're trying to decide if this big, complicated, plural question should be pulled in does it. You know.

C

A

Is it going to throw things off.

C

Exactly and so we can um bubble some of that if we are tracking some of that in ci, um and somebody does have been a pull request that bumps up the complexity by 20 points like ah that's something that I mean should at least be known before, pulling it in not.

E

So, to be fair, we probably checked that code and we probably understand that right. Like yeah. I think it's when you have code like in yy, which you haven't touched in a while, and you know, there's a lot of places where, like like, we haven't gone in and checked out that code. It's just been there sitting there for a long time. Then we can see that from here, loader.js.

C

uh That that is the one that has the most estimated errors, which I I'm sure this is kind of. What I'm saying it's like loader is pretty darn solid um and it- and it has probably it has yeah some complex code in there, but if there were a bunch of if it were the most error-prone module in the library, we would know about it by now so yeah, because it's like it's the pivot point around it right. Yeah, um 99.9 percent of yui usage comes with the motor.

E

That graph above the the blue graph at the top there reminds me of like the skyline of course on.

E

Does anyone know that anyone else not think that oh yeah, just so many skyscrapers, yeah.

C

um Yeah yeah, and so I don't think, there's any anything else in here yeah. Basically, then it just does a breakdown per file. Oh and one cool thing too, is, if you uh click on each file, you can actually see um um here again. I guess we running out of time, but here let me click on like the yui ua file here um and so here.

C

It'll actually have the have the full file, um but so the number of five function uh has statistic: metrics about it as well complexity and length and difficulty an estimated number of bugs, um and so it actually does this.

A

Yeah, really it's a great tool right. It's like you know it could be off, but it's another sort of you know lens that you can apply to your code yeah. How long did it take to run.

C

uh Just like uh I don't know, I ran in a bunch of times uh and I don't think more than like 30 seconds or something for that. Okay, um so yeah.

A

Cool stuff, though yeah yeah I'd love to try that out on the gallery too, to see what what yeah, just because you know you might find some. I find good candidates, for you know this. You know I don't know it's an example. Like hilo said about code. That may not be familiar with, but you want to get a quick shot of how how well it's running yeah yep awesome, that's pretty cool!

A

So last week I spent the whole time going over stale pull requests, so I'm feeling kind of poor still pull requests, fatigue yeah, as you can tell by the music. That's right! That's! What's not fun! That's what stanford request fatigue sounds like.

A

We went through a bunch of these and they've all gotten sort of touched on, there's still some those who are hanging out um there's one that I wanted to bring up just while we're here.

A

um Actually no, this isn't. This is eric one.

A

Trying to think, if there's any of these, that that we should talk to about. But.

D

We covered all.

A

Them last week so, and I want to call out ezekiel for going after a lot of these and knocking them out in terms of either fixing.

E

A

He there was one that was like this long-standing pull request that had a lot of garbage in it and he was able to pull that out and like do a new pull request with just the part. That was the part that was actually wanting to be changed, because that person accidentally, I think, pulled in like a branch or something from somewhere else. Now, there's like 300 files.

F

A

Yeah, so there's that, let's see anything else, someone on um on the dev channel says that they're going to go rush out to check their gallery code now against your tool for.

D

Speaking of gallery, did we have a new gallery push this week.

C

uh I don't know I would.

A

I we usually do it on wednesday, so and eugene is now back, but I don't know if he's going to join us, but um there was something new about the rail stuff right.

A

Oh, we can do that next week, yeah. So we're good. So thanks everybody for coming and you can now click stop on your browser. Everything else is just right now.

D

Cool thanks thanks.