Basic D3.js components tree visualization feat. chatGPT

Vadim Tcaregorodtcev — Fri, 17 Mar 2023 15:37:13 +0000

Before starting this small project, I had heard of D3.js but had never worked with it before. I had not even opened the documentation. Therefore, I decided to experiment with ChatGPT to see how well the neural network could understand what I wanted, even when I was not in the context of what I was asking for.

Now that I am writing this note, I already have a basic understanding of how D3.js works and can probably do similar tasks on my own.

So, the first thing I did was to try to ask for the final result right away, without looking at any examples or documentation. Even though the response from the neural network could not fit within the character limit for the response and had some syntactical errors, the code did not run. Here comes the first insight: D3.js has several versions with breaking changes, and the neural network combined examples from different versions, which led to the code breaking.

To avoid this issue, we can use one of the latest versions that were released before the neural network's dataset was closed in 2021:

<script src="https://d3js.org/d3.v6.min.js"></script>

Next, even in that broken version, the silhouette of our application's code is outlined.

const svg = d3
    .select("body")
    .append("svg")
    .attr("width", width)
    .attr("height", height)
    .append("g");

D3 works with SVG and performs all manipulations with this format. To start working, we need to create a workspace (SVG), set its attributes, and add a "g" element to group other elements that we will add later.

What are these elements?

As we are going to visualize a component tree, the neural network suggests that we need two types of elements: nodes and links that connect these nodes.

In D3, it looks like this.

nodes = svg
    .selectAll("foreignObject")
    .data(data.nodes)
    .join("foreignObject")
    .attr("width", 100)
    .attr("height", 50)
    .html(function (d) {
      return d.content;
    });

links = svg
    .selectAll("line")
    .data(data.links)
    .join("line")

Nodes are created using foreignObject. This tag allows using SVG from a different namespace and is often used for custom HTML content.

The syntax .selectAll.data.join means that we are selecting all the current elements of a particular type (just like "document.querySelector"), then we match each element on the SVG with a real object in the code, and finally call join for those data.something elements that do not have a corresponding element on the SVG canvas.

For example, in the code snippet above, we select all foreignObject elements and bind them with data.nodes, then set their width and height attributes to 100 and 50 respectively, and add HTML content to each of them using the "d.content" function. Similarly, we select all line elements and bind them with data.links using the same syntax.

Accordingly, after calling this code, all corresponding elements for data.nodes and data.links will be drawn on the svg.

To get the full picture, let's look at an example node and link:

// node
{
    id: 1,
    depth: 0,
    name: "name a",
    content: '<div class="node">ROOT</div>',
},

// link
{
    source: 1,
    target: 2,
}

For nodes, we specify the id, and links show how nodes are connected to each other through source and target.

In principle, the basic example is finished. We load data about nodes, create links, and feed them to D3.js. However, if there are too many elements, the nodes will overlap each other, which doesn't look very good. Let's seek help from the neural network.

And then it immediately recommends using forceSimulation, a set of functions for simulating physical bodies, to, for example, prevent nodes from visually overlapping on an SVG element.

simulation = d3
    .forceSimulation(data.nodes) // Force algorithm is applied to data.nodes
    .force(
      "link",
      d3
        .forceLink() // This force provides links between nodes
        .distance(200) // how long links should be 
        .id(function (d) {
          return d.id;
        }) // This provides the id of a node
        .links(data.links) // and this the list of links
    )
    .force("charge", d3.forceManyBody().strength(-400)) // This adds repulsion between nodes. Play with the -400 for the repulsion strength
    .force("center", d3.forceCenter(width / 2, height / 2)) // This force attracts nodes to the centre of the SVG area
    .force("collide", d3.forceCollide().radius(75))
    .force(
      "y",
      d3
        .forceY() // on which level each node is supposed to be 
        .strength(1)
        .y((d) => d.depth * 250)
    )
    .on("tick", ticked); // callback for each time tick

After applying forceSimulation, we get a nearly perfect implementation of the visualization.

You can see an example at the following link: https://jsfiddle.net/tn6mukq9/2/

Your team lead left a company, and you as the last most mature engineer should start a new project?

Vadim Tcaregorodtcev — Sat, 09 Jul 2022 10:21:07 +0000

This is an article from the series "2 mins dev's notes" from github-based blog about dev's daily routine challenges.

Intro

Sometimes, in small companies, it happens that the team leader gets a better offer and leaves the company, leaving their subordinates at the start of a new project. And often, this can put developers in a difficult situation since developers may not have the management experience to organize themselves and confidently start a new project.

The question arises, what to do in this case? What to do when you are the only possible candidate for the team leader position? And you don't mind taking it, of course 😄

Improvise. Adapt. Overcome.

Jk. The very first thing to do is to decide on your role. It is worth mentioning that the position of the developer in the company and their role in the project can be quite different.

For example, a developer is hired as a senior engineer. But on a specific project, they perform the role of a project manager. They often communicate with stakeholders, discuss tasks with the team, plan sprints, and distribute tasks among team members. Or another example, a QA engineer can often play the role of a business analyst, clarifying all project requirements and maintaining documentation.

So this is an important moment when starting a new project. The basic set of roles depends on the project, but most often, at the start, there is always a business analyst, architect, project manager, and designer. These are the roles/people that allow you to determine what exactly needs to be done for the customer.

If at the start of the project it is clear that there are more roles required than people are, then most likely, someone will play more than one role. Accordingly, it is necessary to familiarize yourself with what each role implies.

What's next?

After people have taken their roles, the question arises. According to what scenario will these roles be played? This refers to the principle which will be used in building the processes in the team. I'm sure everyone has heard about waterfall and agile.

More often, preference is given to agile methodologies, such as scrum or kanban, since it is considered that the waterfall is already outdated and often the customer himself may not know what he wants, so a flexible approach with constant feedback is required.

Just in such cases, the business analyst and/or architect at the initial stage may not be able to gather all the requirements for the project. But the base set must still be prepared and then we can say that we have collected the requirements for the MVP, the minimum valuable product, the minimum version of the product that can still demonstrate the basic capabilities.

Typically, such a set of requirements is written in the form of stories, because the human brain perceives stories more easily than diagrams. The story might look like this: "As a user, I want to add products to the cart." The story should include a person and a description of what that person can do.

After the list of such stories is sorted depending on their importance, you can begin to implement them.

Usually, by this point, it is already obvious which technology stack is suitable for the implementation of the project. Therefore, stories are cut into tasks, and tasks are taken by developers to work.

And as you can see, the coding itself comes last, because it is more important to be able to choose a tool for a task than a task for a tool.

Conclusion

The whole text above we can squash into the following steps:

determine your role
determine what you should do in this role
learn a new framework while waiting for the basic requirements gathered
participate in compiling, estimating, and planning user stories
help divide stories into tasks
get to work