[00:00.000 --> 00:26.960]  Okay, thank you for coming and thank you to the organizers as well for organizing this
[00:26.960 --> 00:33.560]  for them and this JavaScript Devroom. I'm Navid Moreno, I'm a PhD student at the University
[00:33.560 --> 00:38.240]  of Rio and Carlos in Spain, Madrid, and I'm going to present you how to visualize the
[00:38.240 --> 00:44.680]  MPM dependency city ecosystem of Junot project in virtual reality. I would like to say that
[00:44.680 --> 00:49.560]  this is not a technical talk, it's just a prototype that I designed, it's more related
[00:49.560 --> 00:56.880]  to academia, I'm a PhD student, so it's kind of some new things and maybe have your opinion
[00:56.880 --> 01:04.160]  on probably if this work is useful or not. So first of all, I'm talking about a city.
[01:04.160 --> 01:10.200]  How many of you know something about cold city? Please raise your hand. Cold city? No?
[01:10.200 --> 01:19.440]  One, two, three, okay, so the city metaphor in visualization is just to take the characteristics
[01:19.440 --> 01:25.720]  and layout of the city and then represent something with them. And the city layout just
[01:25.720 --> 01:32.800]  means quarters and buildings. And in this case cold city is one of the most known tools
[01:32.800 --> 01:40.960]  that uses this metaphor for visualizing Java software code. In this case, its building
[01:40.960 --> 01:50.040]  is a source code of the Java project and the quarter is the level of the source code in
[01:50.040 --> 02:02.120]  the package of the Java project. So in this case, we developed a new version of this city
[02:02.120 --> 02:06.840]  metaphor called city visualization using web technologies, it's related to the last
[02:06.840 --> 02:14.960]  thought that Fabian gave us. We use web XR and WebGL and everything related to web,
[02:14.960 --> 02:22.440]  in this case it's A-frame. How many of you know it's A-frame? Probably more, right?
[02:22.440 --> 02:30.000]  So we changed this metaphor a little bit, changing the algorithm of the layout of the
[02:30.000 --> 02:36.560]  buildings, we use a spiral algorithm instead of a tree map layout because we want to reorganize
[02:36.560 --> 02:42.880]  the buildings in a different way because the layout, the tree map layout is too fixed
[02:42.880 --> 02:50.720]  and when you want to add a new building there, there are many problems. So in this visualization
[02:50.720 --> 02:55.280]  we have metrics that we can represent in the buildings and in the quarters. The quarters
[02:55.280 --> 03:00.720]  represent a tree layout because you know you have quarters, then you can have quarters
[03:00.720 --> 03:06.880]  at the top of the quarters and so on. The buildings have different metrics like the
[03:06.880 --> 03:10.720]  area of the building, the height of the building or the color of the building. We are using
[03:10.720 --> 03:17.720]  this metrics to represent the NPM, the dependencies ecosystem of a project. So if you are in your
[03:17.720 --> 03:23.240]  computer right now or in your mobile phone, I want to invite you to go to that URL or
[03:23.240 --> 03:29.400]  scan this query and then visit this live demo and then you can follow the demo with me.
[03:29.400 --> 03:45.360]  So this is the demo, so this is the city of, sorry, it's tinyurl.com slash varia.force them.
[03:45.360 --> 03:54.160]  Here's the name of the tool that I'm developing in my thesis. Just a minute. With your mobile
[03:54.160 --> 04:01.720]  phone you won't have as many, as the interaction that you can have with your computer but you
[04:01.720 --> 04:08.520]  can have an idea and you can visualize the city. So this is what you can see in the demo.
[04:08.520 --> 04:13.080]  This is the dependency city of a project. In this case it's the user interface of Shorting
[04:13.080 --> 04:22.360]  Hat that is a project for doing things under the Gamer Lab project. So in this case, in
[04:22.360 --> 04:30.440]  this city, each building represents a dependency of the project. What we can see here is that,
[04:30.440 --> 04:34.520]  okay, they are building with different colors and so, but the first thing that we can see
[04:34.520 --> 04:44.680]  here is that the quarters are kind of elevated. We can see here a quarter, what this big quarter,
[04:44.680 --> 04:49.560]  this quarter, this quarter, this quarter, this quarter, and this quarter. This quarter
[04:49.560 --> 04:55.320]  means the dependency level that your application has. And this first quarter, the big one,
[04:55.320 --> 05:02.400]  the first one is like the bottom or the package.json of the Gamer Lab project where you define
[05:02.400 --> 05:08.120]  the first level of dependencies, okay? So we have the elevated city, we have to be clear
[05:08.120 --> 05:20.160]  of this. The second thing that we can see in this city is where the buildings are. Where
[05:20.160 --> 05:27.960]  the building is, the quarter that the building is laying out means that this building or
[05:27.960 --> 05:35.200]  this package is in that level, in that dependency level, okay? For instance, this building is
[05:35.200 --> 05:39.200]  in the first level of dependency that you probably define this package in your package
[05:39.200 --> 05:44.080]  or json if you're not a project or whatever. And these three buildings that are laying
[05:44.080 --> 05:49.720]  out in this level belong to the third level of dependencies of your project, okay? I'm
[05:49.720 --> 05:56.000]  explaining this because it's just a matter of explaining how the visualization works.
[05:56.000 --> 06:03.720]  And some buildings go through a quarter, which means that the building that goes through
[06:03.720 --> 06:10.600]  a quarter is the owner of the dependencies that are in that building, in that quarter,
[06:10.600 --> 06:15.920]  sorry. In other words, this package is going through this quarter, so the dependencies,
[06:15.920 --> 06:21.960]  this, this, and these are suit dependencies of this quarter, of this building, sorry.
[06:21.960 --> 06:29.080]  Okay? Again, for instance, this package is going through this quarter, so these dependencies,
[06:29.080 --> 06:34.440]  these dependencies are suit dependencies of this building, of this package. It has to
[06:34.440 --> 06:41.640]  be clear because it's kind of the core of this visualization. And if you are in the
[06:41.640 --> 06:49.440]  demo, you probably notice that there is kind of some buttons here that are the metrics
[06:49.440 --> 06:57.440]  available in this visualization. These metrics that are here only change the characteristics
[06:57.440 --> 07:07.120]  of the buildings, okay? So, we are going to focus on the third level, first on this row,
[07:07.120 --> 07:13.360]  that is the heap, the heap. I don't know if you can see clear what it says here. H days,
[07:13.360 --> 07:20.760]  okay? Height. This means the height of the buildings. And now, the height of the building
[07:20.760 --> 07:27.760]  represents the age of the package in number of days. Okay? We have this metric, this numeric
[07:27.760 --> 07:33.600]  metric in height. The area of the buildings, we have three metrics. Now, we select this
[07:33.600 --> 07:41.880]  one that is log slash age, which means the lines of code of the package divided by the
[07:41.880 --> 07:47.400]  age in days. And you are probably wondering why divided by the age in number of days.
[07:47.400 --> 07:52.080]  Because if you divide, if you multiply the height of the area of a building, of a box,
[07:52.080 --> 07:56.760]  you have the volume. So, if you compute these two metrics, multiplying them, you can have
[07:56.760 --> 08:03.560]  as a third metric, the volume, as computed metric, in the case the volume of the buildings,
[08:03.560 --> 08:11.120]  will be the lines of code in total. But we can change this metric into size, in the size
[08:11.120 --> 08:21.040]  in bytes, divided by age. We can click on the metric, then the visualization is updated.
[08:21.040 --> 08:24.560]  And the third one is the number of comments that the package has divided by the age in
[08:24.560 --> 08:35.840]  days. But probably, this is not as important because in this project, on this prototype,
[08:35.840 --> 08:43.320]  we are focused on the color of the buildings. And now, you realize why there are many metrics
[08:43.320 --> 08:50.880]  in the row of color. So, by default, what you see as a color building is the type of
[08:50.880 --> 08:56.480]  license that the package has. In this case, we can see that there are many packages with
[08:56.480 --> 09:03.640]  a purple color, kind of a purple. And then, on the right, we have this legend that says
[09:03.640 --> 09:11.880]  which license is using. So, with this color and this city, we can have a quick overview
[09:11.880 --> 09:18.200]  of the packages that are using the same licenses or the same license. Or if a package is using
[09:18.200 --> 09:23.200]  a license that we don't want to have in our projects or so, that's probably one of the
[09:23.200 --> 09:31.040]  goals of this metric color. Then, we have two metrics that is times installed and times
[09:31.040 --> 09:37.960]  disappear. These are not category metrics. These are numbering metrics. These metrics
[09:37.960 --> 09:46.440]  follow a heat map color from blue to red. And this is interesting because I think that
[09:46.440 --> 09:59.960]  you know pretty well the NPM ecosystem. When you are installing a package in NPM, if NPM
[09:59.960 --> 10:05.400]  found a dependency more than once, in the same version, NPM will install the dependency
[10:05.400 --> 10:14.440]  once. We all know that. All of us know that. But if NPM found the same dependency defined
[10:14.440 --> 10:19.480]  in two different versions, then NPM will install the dependency twice, in this case.
[10:19.480 --> 10:27.560]  So, this metric represents, as a color of the building, how many times the dependency
[10:27.560 --> 10:32.160]  of the package is installed. In other words, how many times the dependency is defined in
[10:32.160 --> 10:41.240]  different versions. And this one is how many times the dependency appears in the project.
[10:41.240 --> 10:46.040]  There are less diversions because we are using, for instance, we are developing something in
[10:46.040 --> 10:54.400]  GraphQL and we use GraphQL in many things. We define GraphQL. I don't know a package
[10:54.400 --> 11:00.880]  that uses GraphQL, but then we use another package that uses GraphQL as well. So, this
[11:00.880 --> 11:07.040]  represents how many times this package appears. How many times it is installed there. And
[11:07.040 --> 11:12.800]  these two metrics are completely related to the first line that is the attributes line,
[11:12.800 --> 11:21.880]  I call it. And it's used for changing the transparency or the wireframe of the build,
[11:21.880 --> 11:26.280]  the wireframe features of the buildings. Because now you notice that there are some
[11:26.280 --> 11:32.520]  buildings that are kind of transparent buildings, which means that these buildings are not installed.
[11:32.520 --> 11:39.640]  These buildings are replicas and only the solid ones are the ones that are in this installed.
[11:39.640 --> 11:49.360]  And if we go with our mouse or with our VR controller over a building, we can see that
[11:49.360 --> 11:55.040]  if we hover a building with the mouse, we see here that this dependency is GraphQL and
[11:55.040 --> 12:00.120]  then some other buildings are highlighted in white as well, but only one of them, that
[12:00.120 --> 12:08.880]  is this one, is solid. So, it means GraphQL is defined in many, many locations, but only
[12:08.880 --> 12:21.560]  this is those ones that is there, but appears nine times. We have also metrics related to
[12:21.560 --> 12:26.720]  the community of the, or the package of the community behind the repository of the package.
[12:26.720 --> 12:34.240]  The first one is last at days, which means the days, the number of days since the last
[12:34.240 --> 12:41.360]  commit. So, in a hit map from blue to red, if the package is red, it means that probably
[12:41.360 --> 12:46.240]  this package has no activity in the last. For instance, this, we can see this package
[12:46.240 --> 12:54.920]  here, this is script 002, 2000 years since the last commit. So, probably this is kind
[12:54.920 --> 13:01.080]  of a smell, probably in this kind of visualization. Also, we have the number of commits in the
[13:01.080 --> 13:06.360]  last year of the package, of the repository of the package, the number of unique committers
[13:06.360 --> 13:13.840]  in the last year of the repository of the package, and of course, the number of vulnerabilities
[13:13.840 --> 13:20.200]  that we can find with the MPM audit tool as well. But this visualization has the goal
[13:20.200 --> 13:25.720]  of merge all the information that we can retrieve from the package and then show it
[13:25.720 --> 13:33.200]  in this, this city. And the last one is the number of issues radio that is just the number
[13:33.200 --> 13:39.760]  of issues open of the repository divided by the number of issues closed in all the story
[13:39.760 --> 13:45.560]  of the, of the package. So, this is the first overview of the, of the tool. I invite you
[13:45.560 --> 13:57.120]  to play with it. I was really quick. Of course, where are we? In the, in the, in the slides
[13:57.120 --> 14:03.480]  there are plenty of QRs with links to the documentation, to links to the step by step
[14:03.480 --> 14:08.760]  tutorial in order to have this, this visualization with your own project because what you need
[14:08.760 --> 14:12.520]  is just to have a project installed and then run a set of tool that I'm going to spray
[14:12.520 --> 14:23.080]  right now. But I said that this is for virtual reality. So, in academia, some researchers
[14:23.080 --> 14:29.880]  validated the city metaphor in virtual reality agreeing that the notion of having a city
[14:29.880 --> 14:37.080]  in a, like in a, in a table or something like that helps the, the user or the, the participant
[14:37.080 --> 14:42.640]  of the experiment or whatever to have better information that using a computer or using
[14:42.640 --> 14:50.320]  a 2D screen. So, that's the reason behind this, this research. So, in this case, we
[14:50.320 --> 14:55.280]  are using a MetaQuest 2 glasses. If this is an experiment and then we have in the left
[14:55.280 --> 15:00.560]  controller the user interface that we are already, we're already showing the demo. And
[15:00.560 --> 15:04.880]  then we can see that when you, when we click on the buttons, you see that the, that the
[15:04.880 --> 15:14.840]  city's updated instantly. I didn't tell you, but there is a second line in the user interface
[15:14.840 --> 15:24.600]  because the demo, I forgot that. The demo has four different projects to analyze in
[15:24.600 --> 15:28.200]  this city. Now it's a little shorting hat. That is the project that we are selecting
[15:28.200 --> 15:33.720]  in this project. But also we have the data from the PM2 package. If you know PM2, you
[15:33.720 --> 15:38.840]  can, you can click on it. We can click on the PM2 project and then the city is automatically
[15:38.840 --> 15:46.400]  updated. We have also data from the portainer user interface and the github desktop user
[15:46.400 --> 15:56.080]  interface because it's developed in Node. So, we're going to focus on the data just
[15:56.080 --> 16:07.720]  to finish. This QR will redirect you to this repository where I have all the codes that
[16:07.720 --> 16:14.440]  I use for having the data because this is really, really easy to replicate because what
[16:14.440 --> 16:20.440]  you saw here is just an HTML using A-frame, using Babia that is the tool that I developed
[16:20.440 --> 16:24.680]  and then adjacent with all the data. So now we're going to talk about how to produce
[16:24.680 --> 16:29.000]  adjacent. But you can produce adjacent whatever you want. So it's not a matter of, you can
[16:29.000 --> 16:36.600]  follow this tutorial or not. So the first step is to have your MPM package or application
[16:36.600 --> 16:42.800]  installed. Of course, because we are representing the MPM dependencies application. The second
[16:42.800 --> 16:57.760]  step is to use MPM to have the dependencies list and the vulnerabilities list.
[22:42.800 --> 23:00.360]  Yeah, just a simple question.