Okay, thank you for coming and thank you to the organizers as well for organizing this
for them and this JavaScript Devroom. I'm Navid Moreno, I'm a PhD student at the University
of Rio and Carlos in Spain, Madrid, and I'm going to present you how to visualize the
MPM dependency city ecosystem of Junot project in virtual reality. I would like to say that
this is not a technical talk, it's just a prototype that I designed, it's more related
to academia, I'm a PhD student, so it's kind of some new things and maybe have your opinion
on probably if this work is useful or not. So first of all, I'm talking about a city.
How many of you know something about cold city? Please raise your hand. Cold city? No?
One, two, three, okay, so the city metaphor in visualization is just to take the characteristics
and layout of the city and then represent something with them. And the city layout just
means quarters and buildings. And in this case cold city is one of the most known tools
that uses this metaphor for visualizing Java software code. In this case, its building
is a source code of the Java project and the quarter is the level of the source code in
the package of the Java project. So in this case, we developed a new version of this city
metaphor called city visualization using web technologies, it's related to the last
thought that Fabian gave us. We use web XR and WebGL and everything related to web,
in this case it's A-frame. How many of you know it's A-frame? Probably more, right?
So we changed this metaphor a little bit, changing the algorithm of the layout of the
buildings, we use a spiral algorithm instead of a tree map layout because we want to reorganize
the buildings in a different way because the layout, the tree map layout is too fixed
and when you want to add a new building there, there are many problems. So in this visualization
we have metrics that we can represent in the buildings and in the quarters. The quarters
represent a tree layout because you know you have quarters, then you can have quarters
at the top of the quarters and so on. The buildings have different metrics like the
area of the building, the height of the building or the color of the building. We are using
this metrics to represent the NPM, the dependencies ecosystem of a project. So if you are in your
computer right now or in your mobile phone, I want to invite you to go to that URL or
scan this query and then visit this live demo and then you can follow the demo with me.
So this is the demo, so this is the city of, sorry, it's tinyurl.com slash varia.force them.
Here's the name of the tool that I'm developing in my thesis. Just a minute. With your mobile
phone you won't have as many, as the interaction that you can have with your computer but you
can have an idea and you can visualize the city. So this is what you can see in the demo.
This is the dependency city of a project. In this case it's the user interface of Shorting
Hat that is a project for doing things under the Gamer Lab project. So in this case, in
this city, each building represents a dependency of the project. What we can see here is that,
okay, they are building with different colors and so, but the first thing that we can see
here is that the quarters are kind of elevated. We can see here a quarter, what this big quarter,
this quarter, this quarter, this quarter, this quarter, and this quarter. This quarter
means the dependency level that your application has. And this first quarter, the big one,
the first one is like the bottom or the package.json of the Gamer Lab project where you define
the first level of dependencies, okay? So we have the elevated city, we have to be clear
of this. The second thing that we can see in this city is where the buildings are. Where
the building is, the quarter that the building is laying out means that this building or
this package is in that level, in that dependency level, okay? For instance, this building is
in the first level of dependency that you probably define this package in your package
or json if you're not a project or whatever. And these three buildings that are laying
out in this level belong to the third level of dependencies of your project, okay? I'm
explaining this because it's just a matter of explaining how the visualization works.
And some buildings go through a quarter, which means that the building that goes through
a quarter is the owner of the dependencies that are in that building, in that quarter,
sorry. In other words, this package is going through this quarter, so the dependencies,
this, this, and these are suit dependencies of this quarter, of this building, sorry.
Okay? Again, for instance, this package is going through this quarter, so these dependencies,
these dependencies are suit dependencies of this building, of this package. It has to
be clear because it's kind of the core of this visualization. And if you are in the
demo, you probably notice that there is kind of some buttons here that are the metrics
available in this visualization. These metrics that are here only change the characteristics
of the buildings, okay? So, we are going to focus on the third level, first on this row,
that is the heap, the heap. I don't know if you can see clear what it says here. H days,
okay? Height. This means the height of the buildings. And now, the height of the building
represents the age of the package in number of days. Okay? We have this metric, this numeric
metric in height. The area of the buildings, we have three metrics. Now, we select this
one that is log slash age, which means the lines of code of the package divided by the
age in days. And you are probably wondering why divided by the age in number of days.
Because if you divide, if you multiply the height of the area of a building, of a box,
you have the volume. So, if you compute these two metrics, multiplying them, you can have
as a third metric, the volume, as computed metric, in the case the volume of the buildings,
will be the lines of code in total. But we can change this metric into size, in the size
in bytes, divided by age. We can click on the metric, then the visualization is updated.
And the third one is the number of comments that the package has divided by the age in
days. But probably, this is not as important because in this project, on this prototype,
we are focused on the color of the buildings. And now, you realize why there are many metrics
in the row of color. So, by default, what you see as a color building is the type of
license that the package has. In this case, we can see that there are many packages with
a purple color, kind of a purple. And then, on the right, we have this legend that says
which license is using. So, with this color and this city, we can have a quick overview
of the packages that are using the same licenses or the same license. Or if a package is using
a license that we don't want to have in our projects or so, that's probably one of the
goals of this metric color. Then, we have two metrics that is times installed and times
disappear. These are not category metrics. These are numbering metrics. These metrics
follow a heat map color from blue to red. And this is interesting because I think that
you know pretty well the NPM ecosystem. When you are installing a package in NPM, if NPM
found a dependency more than once, in the same version, NPM will install the dependency
once. We all know that. All of us know that. But if NPM found the same dependency defined
in two different versions, then NPM will install the dependency twice, in this case.
So, this metric represents, as a color of the building, how many times the dependency
of the package is installed. In other words, how many times the dependency is defined in
different versions. And this one is how many times the dependency appears in the project.
There are less diversions because we are using, for instance, we are developing something in
GraphQL and we use GraphQL in many things. We define GraphQL. I don't know a package
that uses GraphQL, but then we use another package that uses GraphQL as well. So, this
represents how many times this package appears. How many times it is installed there. And
these two metrics are completely related to the first line that is the attributes line,
I call it. And it's used for changing the transparency or the wireframe of the build,
the wireframe features of the buildings. Because now you notice that there are some
buildings that are kind of transparent buildings, which means that these buildings are not installed.
These buildings are replicas and only the solid ones are the ones that are in this installed.
And if we go with our mouse or with our VR controller over a building, we can see that
if we hover a building with the mouse, we see here that this dependency is GraphQL and
then some other buildings are highlighted in white as well, but only one of them, that
is this one, is solid. So, it means GraphQL is defined in many, many locations, but only
this is those ones that is there, but appears nine times. We have also metrics related to
the community of the, or the package of the community behind the repository of the package.
The first one is last at days, which means the days, the number of days since the last
commit. So, in a hit map from blue to red, if the package is red, it means that probably
this package has no activity in the last. For instance, this, we can see this package
here, this is script 002, 2000 years since the last commit. So, probably this is kind
of a smell, probably in this kind of visualization. Also, we have the number of commits in the
last year of the package, of the repository of the package, the number of unique committers
in the last year of the repository of the package, and of course, the number of vulnerabilities
that we can find with the MPM audit tool as well. But this visualization has the goal
of merge all the information that we can retrieve from the package and then show it
in this, this city. And the last one is the number of issues radio that is just the number
of issues open of the repository divided by the number of issues closed in all the story
of the, of the package. So, this is the first overview of the, of the tool. I invite you
to play with it. I was really quick. Of course, where are we? In the, in the, in the slides
there are plenty of QRs with links to the documentation, to links to the step by step
tutorial in order to have this, this visualization with your own project because what you need
is just to have a project installed and then run a set of tool that I'm going to spray
right now. But I said that this is for virtual reality. So, in academia, some researchers
validated the city metaphor in virtual reality agreeing that the notion of having a city
in a, like in a, in a table or something like that helps the, the user or the, the participant
of the experiment or whatever to have better information that using a computer or using
a 2D screen. So, that's the reason behind this, this research. So, in this case, we
are using a MetaQuest 2 glasses. If this is an experiment and then we have in the left
controller the user interface that we are already, we're already showing the demo. And
then we can see that when you, when we click on the buttons, you see that the, that the
city's updated instantly. I didn't tell you, but there is a second line in the user interface
because the demo, I forgot that. The demo has four different projects to analyze in
this city. Now it's a little shorting hat. That is the project that we are selecting
in this project. But also we have the data from the PM2 package. If you know PM2, you
can, you can click on it. We can click on the PM2 project and then the city is automatically
updated. We have also data from the portainer user interface and the github desktop user
interface because it's developed in Node. So, we're going to focus on the data just
to finish. This QR will redirect you to this repository where I have all the codes that
I use for having the data because this is really, really easy to replicate because what
you saw here is just an HTML using A-frame, using Babia that is the tool that I developed
and then adjacent with all the data. So now we're going to talk about how to produce
adjacent. But you can produce adjacent whatever you want. So it's not a matter of, you can
follow this tutorial or not. So the first step is to have your MPM package or application
installed. Of course, because we are representing the MPM dependencies application. The second
step is to use MPM to have the dependencies list and the vulnerabilities list.
Yeah, just a simple question.