DEV Community: Bob Cavezza

The Simple Guide to HTML SVGs

Bob Cavezza — Tue, 27 Aug 2019 20:44:18 +0000

You want to work with D3, but you don’t understand how SVGs are rendered in the browser. This makes it very difficult to understand HTML code that D3 outputs. Let’s tackle some of these issues.

The code we will be looking at today was generated by D3. However, in this example, we’re not looking at D3. We’re looking only at the SVG code rendered in HTML.

This is very important because when working with D3, you will typically be creating SVGs. If you’re not familiar with how an SVG looks and behaves, debugging D3 code will be very difficult.

Before getting started, I want you to keep one thing in mind when looking at this code. SVG code, in its simplest form, is putting shapes on a canvas. In the example below, we will draw an SVG canvas and place shapes and text on that canvas. That’s all we’re doing. Don’t let this code deter you. It’s nothing more than drawings a canvas, and then drawing shapes on that canvas. There might be syntax you’ve never seen before, but learning is fun!

See the Pen Displaying an SVG graph in HTML by Bob Cavezza (@cavezza) on CodePen.

Don’t forget that CodePen is interactive! You should interact with the CodePen and play around with the values. Change some values, see what happens. Remove an element and see how it changes how the graph is displayed on your screen.

Let’s start looking at the code.

First, we have an <svg> tag that is creating an area where we can draw the elements we see. In essence, this tag is drawing our canvas. This creates a canvas that is 600 pixels wide and 400 pixels high. Now that we have the canvas ready, it’s time to start putting shapes on that canvas.

Now, to place items on this canvas, we have to tell the canvas the x and y coordinates for each item. On an SVG canvas, the coordinates start at the top left. If we want 0,0, that would be the very top left. If we want 600,400, that would give us the very bottom right. The graphic below should help explain this better than text can.

Let’s continue looking at the code. The next line of code is:

<g class="axis axis-y" transform="translate(40, 40)" fill="none" font-size="10" font-family="sans-serif" text-anchor="end">

<g> is an interesting sub element of <svg>. It’s the only element besides <svg> itself that isn’t drawing a shape. <g> a container that is used to group other SVG elements. “The important aspect of a <g> element to know is that transformations applied to the <g> element are performed on its child elements and its attributes are inherited by its children” (from Mozilla mdn). You can test this out in the CodePen by taking the transform of a grouping element, removing it from the g element, and putting it on each of its descendants.

What’s important to note is what the transform attribute does. Transform defines a list of definitions that are applied to it and its children. The most common one you often see is translate(x, y). What this does is moves the item and its children to the right x amount of pixels and down y amount of pixels.

There are other, more complex transform options. You will be able to do some really cool animations when you learn transforms well and combine them with animations in D3.

In the next line, we encounter the <path> element.

<path class="domain" stroke="#f00" d="M-6,0.5H0.5V320.5H-6"></path>

Path is an intriguing element and what I believe to be the most complex element in SVG land. In the <path> element, the magic happens in the d= area. I am still not able to decipher what the specific values inside the d attribute do in a path element. When you draw more complex line graphs, that value can grow to hundreds or thousands of characters. What a path does is draws on the canvas. It is used to draw more complex objects than simple shapes.

The <path>in our example is the only one that isn’t a simple line or a simple shape. This particular <path> object draws a line with two ends sticking out of it. Instead of a typical line that looks like | (a line), they look like ] (a line with two lines sticking out at the ends). This might be the simplest <path> element you’ll ever see as they get extremely more complex.

Here’s a screenshot of changing the color of that path so you can fully understand what I mean.

In this screenshot, the fill color of the y axis was changed so you can see the exact shape that hte path object is drawing.

Although we’re not looking at it here, <path>s are where D3 really starts to shine. Since the values in the d attribute are so complex, a tool like D3 is important to be able to write code that other developers will understand when building these complex path objects.

On the next line, we run into the <g> element again.<g class="tick" opacity="1">

Since we discussed the <g> element earlier, we now know that this will add the tick class to all of its descendants and will also pass the opacity of 1 to all of its descendants (two elements – a <line> element and a <text> element).

Next, we see the <line> element. As you might have guessed, a line element draws a simple line: <line stroke="#000" x2="520" transform="translate(0,29.59)"></line>

Stroke is the color of the line. x2 is the x coordinate where the line ends. x1‘s default value is 0. Since there are no values for x1, y1, or y2, we know that they all default to 0. Due to the inherited transforms, this specific element’s own “grid system” starts where the transforms have it start.

Next, we run into the <text> element. And this SVG element does exactly what you expect it to, it renders text on the SVG canvas. The reason we have a <text> element within SVG elements is so you can place it on the canvas by giving it x and y coordinates.

The x attribute tells you where that element should be placed on the xcoordinate plane. The dy attribute is a little different. This tells you where the element should be placed on the y axis in comparison to the previous element. In this example, we are placing it 0.32 ems away from the line element before it. If you’re not familiar with em, it’s the same as the computed font-size of an element. Alternatives to use (instead of an em) are pixels or rems. You can also use percentages in the dy attribute.

What this first pattern does that we just looked at is draw the y axis and the horizontal lines along the y axis. Then, it draws the horizontal line on the grid next to 90 and placed the text of 90 onto the grid.

Now, you will see this pattern repeated a few times as the rest of those horizontal lines and text field numbers are placed on the grid.

Once that is complete, you will see an almost identical grouping of elements that add values to the x axis. Here is the complete code that draws all the lines of the canvas (not including the graph rectangles themselves). You should now be able to understand this entire block of code since we went through all of the building blocks above.

<g class="axis axis-y" transform="translate(40, 40)" fill="none" font-size="10" font-family="sans-serif" text-anchor="end">
    <path class="domain" stroke="#f00" d="M-6,0.5H0.5V320.5H-6"></path>
    <g class="tick" opacity="1">
        <line stroke="#000" x2="520" transform="translate(0,29.59)"></line>
        <text fill="#000" x="-10" dy="0.32em" transform="translate(0,29.59)">90</text>
    </g>
    <g class="tick" opacity="1" transform="translate(0,126.56)">
        <line stroke="#000" x2="520"></line>
        <text fill="#000" x="-10" dy="0.32em">60</text>
    </g>
    <g class="tick" opacity="1" transform="translate(0,223.53)">
        <line stroke="#000" x2="520"></line>
        <text fill="#000" x="-10" dy="0.32em">30</text>
    </g>
    <g class="tick" opacity="1" transform="translate(0,320.5)">
        <line stroke="#000" x2="520"></line>
        <text fill="#000" x="-10" dy="0.32em">0</text>
    </g>
</g>
<g class="axis axis-x" transform="translate(40, 360)" fill="none" font-size="10" font-family="sans-serif" text-anchor="middle">
    <path class="domain" stroke="#000" d="M0.5,6V0.5H520.5V6"></path>
    <g class="tick" opacity="1" transform="translate(87.16,0)">
        <line stroke="#000" y2="6"></line>
        <text fill="#000" y="9" dy="0.71em">Mon</text>
    </g>
    <g class="tick" opacity="1" transform="translate(260.5,0)">
        <line stroke="#000" y2="6"></line>
        <text fill="#000" y="9" dy="0.71em">Tues</text>
    </g>
    <g class="tick" opacity="1" transform="translate(433.83,0)">
        <line stroke="#000" y2="6"></line>
        <text fill="#000" y="9" dy="0.71em">Wed</text>
    </g>
</g>

What’s left is the drawing of the graphing elements themselves. At this point, I’m not sure if you would be surprised or expecting to learn that these three graphing elements are nothing more than rectangles.

Here is the full code to build the three rectangles on our graph:

<rect class="bar-line" transform="translate(40, 40)" height="320" width="153.33" x="10" y="0"></rect>
<rect class="bar-line" transform="translate(40, 40)" height="203.63" width="153.33" x="183.33" y="116.36"></rect>
<rect class="bar-line" transform="translate(40, 40)" height="132.52" width="153.33" x="356.66" y="187.47"></rect>

<rect>s are one of the more simple SVG elements. You apply a height and width, and then also the starting x and y coordinates.

And that’s it for this visualization!

At this point, you know enough SVG code to be able to create graphs that you can reasonably expect to be needed at your job. Congratulations! Most people don’t fully understand SVGs in order to explain it to other engineers.

Today, you achieved that milestone!

At this point, you probably didn’t fully understand one or two of the elements from the CodePen. If that’s the case, you should go and change some of the CodePen values to see what happens to the visualization when those values are changed. Playing with code is the easiest way to make sure you understand it.

Get my periodic email with the best resources and links online
https://tinyletter.com/rcavezza

Read more at my blog

http://ibuildmvps.com

Connect with me

http://twitter.com/cavezza

http://linkedin.com/in/cavezza

Create a Graph Fast With This Simplest Guide to D3

Bob Cavezza — Tue, 27 Aug 2019 02:37:58 +0000

D3.js does two things: (1) It adds HTML to a page and (2) it binds data to that HTML. That’s it. The simplest example of this you will ever see of D3 data are bar charts binded to pixel size. Most examples of D3 in the wild use SVGs or Path html elements. Understanding those are almost different skills entirely. In this tutorial, we’re going to look at D3 code that does not require any knowledge of SVGs or Paths whatsoever.

Caveat: This isn’t a graph that you would want to put into production. This is a very simple example showing what D3 does.

Let’s take a look at some code and then dissect it to see exactly what’s going on behind the scenes.

See the Pen The Simplest d3 example you’ll ever see by Bob Cavezza (@cavezza) on CodePen.

As you can see, this code is generating a bar graph with no labels and no axes. In this post, we will dissect the code line by line to see what is happening.

If you want to recreate this, you will need all three elements as seen in the CodePen. You need the html and to load the d3 script into your page. You will also need to style the single-line-bar class. The most important part of this code is the javascript section as that is where we’re using D3. Let’s dive into the code.

const data = [4, 30, 15, 16, 23];

d3.select('#chart')
  .selectAll('div')
  .data(data)
  .enter()
  .append('div')
  .classed('single-bar', true)
  .style('height', (d) => ( d + 'px'));

The very first line is the data we will graph. const data = [4, 30, 15, 16, 23]; is a plain javascript array containing five integers. In the next line, we start to see D3 specific syntax.

The first line of d3, d3.select('#chart') works in the exact same way that a CSS selector works. You are selecting the area in your HTML where you want to create your visualization. These selectors work in the exact same way they would work in any front end framework. #s are appended for ids, .s are appended for classes, and any HTML element would be selected like d3.select('div'). Other selectors will work too,

The next thing that you will notice is that D3 supports chaining. Notice there isn’t a semicolon after the first line. The result of the first line is an object that we can chain additional d3 commands to. This is neat because the output of every method can then be used by the next method.

The next line, .selectAll('div'), selects all divs that live inside #chart. This is intriguing because there are no divs that live inside the #chart div in our sample HTML. When this occurs, D3 returns an empty selection. I know this is confusing, but let’s continue to break down the rest of the code and this will make sense soon.

The magic starts to happen in the next line. In .data(data), we are binding data to the div elements. .data is calling the data method in d3. Thedata variable inside the parentheses is a reference to our array of integers we want to graph. We initialized this variable on the first line of our code. The data is now binded to our d3 object, but we still have the issue that there are no divs inside the #chart element. So we’re binding this data to nothing?!?!?

This is where .enter comes into play. If there is a mismatch in number of elements we have selected and the data we binded it to, .enter() allows us to add div elements to make up the difference. .enter() is usually followed by an .append. Our example here is no different.

Important note: There is a corresponding exit method that can be used to remove elements in a similar way that enter adds elements.

Now that we called .enter(), we now have to append values to the selection to bridge the gap from 0 divs to the number of integers in our array. Since we call .append('div'), what this does is adds the difference of number of divs to get to 5 (the length of our array).

If you cut off the rest of the code here, you will see 5 empty divs inside chart.

Here, you can see that if you don’t add the single-bar class and the styled height, your html will still render on the page, but it will not display since it’s not styled and it has no height.

.classed assigns a class to all the divs you are appending if the second parameter is true. In our example, .classed('single-bar', true) assigns a single-bar class to every div that we just appended because true will always be truthy.

The final line .style('height', (d) => ( d + 'px')); adds an inline style attribute to every div that we appended. The first parameter defines the inline style element. The second parameter is a javascript function with d referring to each specific item in our data array.

If you’re not familiar with fat arrow functions, don’t worry. The line is the exact same as the following:

.style('height', function(d) {
    return d + 'px';
}

You can call d whatever you want, but d is generally the convention you’ll see in D3 code. Since d refers to each data item in the array, the first appended div element, it will render as style="height: 4px;".

As you can probably tell, all this D3 code is doing is creating HTML elements. That is all D3 does! It creates and binds data to HTML elements.

In our example above, the d3 code created this html output:

<div id="chart">
    <div class="single-bar" style="height: 4px;"></div>
    <div class="single-bar" style="height: 30px;"></div>
    <div class="single-bar" style="height: 15px;"></div>
    <div class="single-bar" style="height: 16px;"></div>
    <div class="single-bar" style="height: 23px;"></div>
</div>

Don’t forget the importance of the CSS in this example. If you comment out the css in the CodePen, the graph stops appearing.

A screenshot of our CodePen guide showing that if you comment out the css, the graph will not display

This happens because when you create empty divs, there is no minimum width. You are left with HTML elements that you created , but cannot see.

The CSS in our example sets the width of each div, assigns space in between each div, sets the background color of each div, and sets a display value so they will display next to each other like a graph.

.single-bar {
    display: inline-block;
    background: #4285F4;
    width: 8px;
    margin-right: 2px;
}

There is a lot of buzz around D3 because of the crazy graphs it helps create. Everything will get much more complicated as you need to build more complex visualizations. You will need to learn SVGs and Path HTML elements. But don’t let D3 scare you. At the end of the day, it’s just HTML, CSS, and javascript.

Get my periodic email with the best resources and links online
https://tinyletter.com/rcavezza

Read more at my blog

http://ibuildmvps.com

Connect with me

http://twitter.com/cavezza

http://linkedin.com/in/cavezza

How do you add images to the feed for a post?

Bob Cavezza — Mon, 26 Aug 2019 22:39:02 +0000

I tried using cover_image in the metadata. That applied an image to the post itself, but the image didn't appear in feeds for that image. For example, images appear like the following:

Is there something additional you need to do in order to make this happen?

Here are my guesses:
1.) Cover images need to fix certain width/height constraints to appear in the feeds
2.) Images need to be approved to appear in the feeds
3.) There's another metadata tag I need to add to posts.

Any help would be appreciated.

For additional context: Here's a screenshot of my post with the cover_image.

Here's a screenshot of my post in the feed:

A Linter: The Magic Bullet To Improve Your Engineering Team

Bob Cavezza — Sun, 25 Aug 2019 18:49:12 +0000

A linter is formally classified as a Static Code Analysis tool. It is usually a command line tool and it parses a project’s code to look for patterns. It then checks the patterns it finds against generally accepted standards (or custom rules you think are important).

The primary purposes of a linter are to find errors, find bugs, and help enforce a standardized coding style in a project. When you implement a linter, it will do much more!

In the javascript ecosystem, the linters you will see most often are TSLint and ESLint. Both can be installed via npm and can make your software development lifecycle much faster.

In this post, I’m going to discuss why linters are important. Then, I’m going to show the typical ways in which linters are used.

Note: Most of my recent work has been in Angular. All examples in this post are using TSLint by way of the angular command line ng Lint

Linting is very important for a well functioning engineering team.

It finds errors in your code.

Let’s take a look at a quick example.

Here’s a common scenario that happens when writing code: a typo. Take a quick look at how the linter in your IDE would handle this.

Common Linting Scenario

A linter will catch this very quickly and you won’t think twice about it. Since the typo is underlined, you fix it very quickly and it takes less than two seconds. Imagine a scenario where you didn’t have a linter hooked up to your IDEA. You may continue writing code until you want to see how this works in a browser (let’s assume you’re not doing TDD in this example).

If you didn’t have a linter installed, you would probably continue writing code until you reached a point where you wanted to test it. You would upload your browser and it wouldn’t behave as expected. Maybe the date doesn’t look as expected. You might run a debugger or console.log a few items to see what’s occurring. Let’s say that it takes you less than 5 minutes to find the bug and fix it. Maybe it takes 30 seconds. Regardless, this could have been fixed in two seconds if you had used a linter. These little things add up over the course of a day, a week, a month, and a year.

Without a linter, finding the bug in your testing is the best case scenario. What’s the worst case scenario? Maybe, you never noticed a bug at all and this made it into production. I can easily imagine a scenario where you’re working with a codebase that has limited or no test coverage.

It increases team morale

Did you ever have a pull request that was torn to shreds by your fellow engineers? It’s not a fun experience.

Pull Requests numerous comments are bad for an engineer’s ego

It hurts your confidence. It can sometimes damage relationships with fellow engineers if they are brash with their comments.

Sometimes with on a PR with numerous comments, an engineer might hold back from commenting on other things.

A linter helps alleviate these issues by cutting down on comments related to coding style, clear mistakes, and bugs. When you hook a linter up to your Continuous Integration Pipeline or Continuous Deployment Pipeline (will be referred to as CI/CD pipeline in the rest of the article), you find those issues and stop the build before this gets to the pull request step.

Since a pull request now can’t get opened with these stylistic issues or clear errors in the code, this reduces the comments fellow engineers might make on a pull request.

This helps increase confidence of the individual engineer opening up the PR and reduces resentment towards other engineers.

It forces a cohesive, agreed upon style

Imagine you are a junior developer and you just opened up your first pull request. You are very proud of this accomplishment!

About an hour later you get your first comment. Veronica suggests that you should use a fat arrow function instead of the traditional javascript syntax. You’re eager to get this first pull request merged, so you quickly make that change and push code back up.

A half hour later, you get another comment on your PR. This time, it’s Michael suggesting that the code you just changed to a fat arrow function might be better off in the traditional javascript syntax.

Shit.

This happens to junior developers all the time.

Engineers come in all shapes and sizes. They come from different backgrounds and worked with different languages in the past. Good engineers are opinionated. Good codebases are opinionated too.

An agreed upon style is important for modern teams. You should have a style guideline that is supported by linting rules. If your team prefers fat arrow functions, make sure that’s a linting rule. If it prefers traditional javascript functions, make sure that’s the rule.

Your team should follow these rules unless there’s a few good reason to break it.

This helps code readability, code understandability, and the junior engineer experience.

It helps create a better overall architecture

Now that small errors and stylistic issues are being caught by the linter, peers on your team can now focus on other issues in your code.

Maybe the code doesn’t make use of the new architecture your team has adopted. Maybe there’s an inefficient line of code that will take long to execute as you scale. Maybe you named a function in a confusing way that might trip up others in the future.

Now that these style issues, clear bugs, and minor issues have been caught in the linter, the engineers on your development team can focus on deeper, more important issues.

This in turn, helps create a better overall architecture and codebase.

In practice, you would typically use a linter in three different places

These were all mentioned earlier in this post, but I wanted to make sure I mentioned them all explicitly here.

In your IDE

When connected to your IDE, linting errors will be underlined automatically so you can see them in real time when writing code.

Common Linting Scenario

In the command line

You can take a look at all the linting issues in your codebase by typing a command into your terminal. In an angular project, you would type ng lint.

In Your CI/CD Pipeline

Your CI/CD pipeline will use the terminal command to run the linter in your pipeline. You can then set the rules as you see fit to fail a build when a certain threshold is crossed.

A linter is engineering team’s best friend. They make your team faster, they make your team happier, they increase overall code quality, and they prevent bugs from getting into production.

Get my periodic email with the best resources and links online
https://tinyletter.com/rcavezza

Read more at my blog

http://ibuildmvps.com

Connect with me

http://twitter.com/cavezza

http://linkedin.com/in/cavezza

Always Be Improving

Bob Cavezza — Tue, 20 Aug 2019 01:46:16 +0000

You should always improving, but should you strengthen a strength or improve a weakness?

Getting better is difficult. You need to make time to improve. I’m pretty good at that. What I’m not good at is picking an area to work on.

On any given evening, I’ll think to myself, “Should I strengthen a strength or should I improve a weakness?” It’s a tough question. There’s no definitive answer.

In fact, I read between 3 and 10 books at a time (There’s a lot of benefits to this!). In any given evening, based on my challenges of the past day or my mood, I’ll pick up a different book. I’ll read a few pages. I’ll learn something new or interesting. Then, I’ll write some notes in my notebook.

Some nights I’ll read a book that will help me get better at something I’m good at. Maybe this would be front end development or management. Other nights, I’ll work on something I know I need to improve. These days, this is usually something like executive presence, strategy, or infrastructure.

I’m currently working towards a Master’s Degree in Software Engineering at Harvard University’s Extension School. For weeks, I’ll go back and fourth on which courses to take. Should I work on something that will help me improve my day to day work? Should I work on something that I have no knowledge of whatsoever? Should I put every possibility in a top hat and pick one at random?

Last Fall, I decided to take a DevOps course. It focused mostly on AWS and its services. I learned about S3, EC2, VPCs, Internet Gateways, Nat Gateways, Cloud Formation, Ansible, Jenkins, and a few other technologies and services. This was a textbook “improving a weaknesses” strategy.

Earlier this Spring, I took “Internet Applications using Node.js and Angular“. This was textbook example of the “strengthening a strength” strategy. At FINCURA, I wear multiple hats. One of those hats is the frontend architect – and we use Angular. Needless to say, I learned a few interesting tidbits about Angular I didn’t already know. It was also fun to learn more about Node.

This Fall, I’m getting out of my comfort zone and taking two classes! I’m going to strengthen a strength (Data visualizations with a focus on d3) and improve a weakness (Java! “Java, Hadoop, Lamba Expressions, and Streams).

It’s your call if you want to strengthen a strength or improve a weakness. There’s no right or wrong answer. You can even be like me and do both depending on your mood.

The key is to always be improving. Always try to get better. People often overestimate what they can do in a week, but underestimate what they can do in ten years. Keep moving. Keep improving.

Front End Architecture for Angular Applications

Bob Cavezza — Tue, 07 May 2019 00:44:55 +0000

In my current role as Director of Product Engineering at FINCURA, I’m often thinking about our front end architecture. For our front end application, we use Angular.

Angular architecture comes down to three main players: services, container components, and presentation components.

I’m going to explain each of these pieces separately, but to get a snapshot of what’s going on, take a look at this diagram:

[Image by Claudo Clavijo from his slideshare deck at https://www.slideshare.net/paucls/angular-and-redux]

Services

Services will do the heavy lifting for your application. They should contain all business logic in your application because business logic will typically be used system-wide. In order to ensure maximum reusability, make sure you can access business rules easily. Angular’s dependency injection for services makes it trivial to reuse service methods site-wide.

If you’re not using Redux, you will want to store system-wide state in services. One common example is keeping the current logged in user as a variable in the UserService. It is an alternative option to store common state in a system-wide container component that is the master parent. However, if you do this, there will be instances in your application where you pass a user variable down in many places. You can expect most components to need the user variable at different times. I call this “Input() Hell” and it’s not all that different from “callback” hell.

Services don’t have any visual output. They process data for components and then components are the part of the infrastructure that display information.

According to Angular’s official documentation, “(services are the easiest files to unit test". Generally, when you test services, you don’t need to worry about the Angular TestBed. Services aren’t much more than regular javascript classes. My go-to method for testing services are to instantiate the service classes with their dependencies mocked with jasmine’s “createSpyObj” method. Once I do that, I can write tests as if I was dealing with a regular javascript class. Here’s a quick example of a test I wrote a few weeks ago:

describe('PortfolioService', () =\> {
  let portfolioService: PortfolioService
  const apiServiceSpy = jasmine.createSpyObj('ApiService', {'send': of( {   response: { objects: [] }} ) } );

  beforeEach(() =\> {
    portfolioService = new PortfolioService(apiServiceSpy);
  });

  describe('#cssColorNumber', () =\> {
    beforeEach(() =\> {
      const portfolios = [
        { name: 'Portfolio1', id: 0 },
        { name: 'Portfolio2', id: 1 },
        { name: 'Portfolio3', id: 2 },
        { name: 'Portfolio4', id: 13 },
        { name: 'Portfolio5', id: 14 },
      ]; 
      portfolioService.portfolios = portfolios;
    }); 

    it('returns id index +1 of id found', () =\> {
      const expectedResult = 5;
      const result = portfolioService.cssColorNumber({name: 'Portfolio5', id: 14});
      expect(result).toEqual(expectedResult);
    }); 
  });
});

In the test above, we are testing the output of a method that returns the index+1 of objects found in an array by their id. Before each test, we instantiate the service class with a mocked dependency injection. We apply sample data to the service we are testing. Then, we are able to test this with a simple expectation. No TestBed needed and no complicated setup that typically comes with the TestBed.

In summary, services should contain all business logic for your application, contain shared state over different pieces of the application, perform all api calls, and have no visual output. They are also much easier to test than presentation components.

Container Components

Container components get their name because they contain presentation components, and always pass data down to these presentation component layers. They are sometimes referred to as smart components. In many cases, you will have nested container components that pass data down to other containers, which eventually pass data down to presentation components.

It’s difficult to get a true sense of what this looks like without an example, so let’s take a look at how this works in practice.

Let’s take a look at my LinkedIn homepage. This is what I see when I log into LinkedIn.

[click image to enlarge]

Here’s an attempt to break this up based on what I assume LinkedIn’s container components and presentation components are (in their front end architecture). Note: Most of my abilities to mock up container components and presentation components comes from reading Thinking in React.

The different colors represent the hierarchies of container components. The main focus for drawing components in this example is the left side navigation bar and all of its parents (which are also container components). The entire page is wrapped by a red line. This will typically be called “app-component” in an application. The next yellow layer of hierarchy separates the top navigation bar from the main wrapper component, which will represent the body of the page. The pink layer is the container for the sidebar. After that, the orange breaks up each of the clearly separated panels. Then the panels are further subdivided into separate child components. The red, yellow, purple, and orange are all container components. Once we get past that, it’s a little more hazy depending on what exactly the application is doing and how granular LinkedIn builds its presentation components. Once you get down to the green layer, you are now looking at presentation components. It’s pretty easy to tell how the top 2 green rectangles and the bottom two green rectangles are probably reused presentation components based on how similar they look.

In our Angular application, we utilize a technique that React has made famous called “lifting state up” (https://reactjs.org/docs/lifting-state-up.html). This means that we store the state used by numerous different components at their lowest shared parent component.

Let’s use LinkedIn’s homepage for this example as well. In our current working example, we have one instance of a user’s avatar on the page. A product manager has come to us and has told us that she wants to add a new item to the top navigation component that contains the user’s avatar. The mockup she gives us looks like this:

[The mockup our PM has given us. Click to enlarge]

If we look closely at the page that we marked up with the component structure, we can see that we already have the avatar on the page. One option is to call our user service again as part of the navigation component, but http calls are expensive. Instead, we want to move where we store the user’s avatar information up to a common parent of both the side navigation bar and the top navigation header. That common parent is the component that we highlighted with a red outline – “app-component”.

If we are currently calling the UserService.getUser method in the orange panel container component, we will now want to call that method in app component (the red wrapper). Then, we will pass down the avatar url as “@Input()”s down to the yellow, down to the maroon, and then down to the orange, where it lived to begin with. We will also pass that same value down to the yellow navigation component and to its children where the new html element will live and display the avatar on the navigation bar.

Containers do not do a lot of heavy lifting for the visual components, but they do have a key presentation responsibility. That responsibility is the placement of presentation components. A good rule of thumb is that you don’t want presentation components to have margin css attributes. The positioning of presentation components should generally be controlled by their parent container components.

Testing container components is generally the hardest of the three types of files we discuss in this article. The main reason for this is the handling of state. State changes and angular lifecycle methods need to be tested. This causes added testing complexity. A key reason to separate out container components and presentation components is so you test container components less and presentation components more.

Presentation components

Presentation components are sometimes referred to as “dumb” components, used mostly to display information. Presentation components will inherit all data and events (@Input()s and @Output()s) from parent components. They are entirely visual output components.

Continuing with our LinkedIn example, we can see a presentation wrapped in green:

This presentation component is used four times on this page, in two separate places. You can reasonably guess what the inputs and outputs are for this presentation component.

The inputs and outputs for this component will probably look something like this:

@Input() label  
@Input() value
@Output() onClickLabel
@Output() onClickValue

These inputs and outputs are passed in by their parents.

Why separate container and presentation components?

There are three reasons: (1) reusability, (2) testability, and (3) ease of use for HTML/CSS designers.

(1) Reusability

If you break components down into smaller and smaller pieces, you will be able to reuse different components in different areas of your code. You can see this in the LinkedIn example with the green outlines on the sidebar. This is all about the “DRY” (don’t repeat yourself) principle. If you didn’t break those green outlines into presentation components, you would have coded the same thing twice. If you later got instructions to change something there, you would have to make changes in multiple places. Doing this usually leads to bugs.

(2) Testability

Presentation components are much easier to test than container components. When you remove state and lifecycle methods as concerns, testing is much easier. Yes, you do need to test container components. It’s a part of writing good, maintainable code. However, the more testing you can do in presentation components, the better off you will be.

(3) HTML/CSS Developers

Many software teams have varying degrees of skillsets. It is not unusual to have someone on the team that knows HTML and CSS really well, but little javascript. When you separate presentation components and container components, it is now a lot easier for HTML/CSS specialists to tweak design-related code. Using a tool like Storybook works wonders on letting HTML/CSS developers control design elements.

Conclusion

This architecture has worked well for us. Separating logic into services, container components, and presentation components has made testing easier. Having a well tested codebase has allowed us to have a much more stable application.

Breaking components down into presentation components has increased our code reusability. Code reusability has allowed us to deliver features faster and introduce less bugs.

Read more at my blog
http://ibuildmvps.com

Connect with me
http://twitter.com/cavezza
http://linkedin.com/in/cavezza

9 software engineering job search and interview tips from the last 3 years

Bob Cavezza — Mon, 26 Jun 2017 01:33:10 +0000

Over the last three years, I was at a startup, a large company, and a smaller company inside a larger company. I’ve interviewed. I’ve been interviewed. I’ve been the deciding vote and I’ve watched great people get passed over. I’ve seen whiteboarding, pair programming, coderpad technical interviews, hacker rank challenges, take home assignments, written tests, and just about everything else you can imagine.

Here are the things I’ve learned during this time. This post should help you if you’re looking for new opportunities, if you were recently laid off, or if you’re fresh out of college or a coding school.

Finding Opportunities

Make a list of companies you want to work for

This is probably my favorite part of looking for a new job. You have a blank canvas. You can work anywhere. Ever wanted to live in Hawaii? Hell – now’s the time. Ever wanted to work for a cool company like EA Sports, Google, or Facebook? Put it on your list. The world is your oyster. Don’t limit yourself to companies similar to where you’ve worked at in the past.

Also – ignore job postings. A lot of great positions are filled by internal referrals and never get posted to job sites. If you put in the time, you should be able to get a referral for almost any company you’re interested in applying to.

I would suggest making a list of at least 15 companies to give you a chance to sample many different types. You don’t want to limit your search to just a few companies, but rather, a larger pool. Some people you will email and will never respond. This can get disheartening if you’re only waiting for that one email, but if you’re looking at 15 different companies at once, you won’t fixate on one person not getting back to you. You should also view this like a conversion funnel. X% of the jobs you apply to will give you a phone call. A percentage of that number will get you on another call for a technical interview. A percentage of that number will bring you in for an in-person interview. A percentage of that number will give you an offer. In an ideal world, you will have multiple offers you can choose between.

This may be difficult to keep track of, so I highly recommend keeping a Google spreadsheet of all current opportunities. Also, you should add companies to the pipeline as opportunities don’t turn into offers.

Always look for a referral

You should always look for a referral for any opportunity.

A friend in HR once told me that hiring a friend is better than hiring a friend of a friend. Hiring a friend of a friend is is better than a referral from someone you work with. And a coworker’s referral is better than a random resume from a job board.

When it comes down to a decision to hire someone, it always makes hiring managers feel a little better if someone is vouching for that person – even if its subtle. Put yourself in the hiring manager’s shoes. Random people are risky. There’s no one vouching for them.

In an ideal scenario, your best friend works for the company you are applying to, but it’s more likely that you have a common LinkedIn connection. When you do, reach out to the common connection. Let them know you’re interested in working at their connection’s company and then ask for an introduction via email or on LinkedIn.

If your mutual friend sent the intro, you should thank your friend for the intro and then ask that other person for coffee. I would tell them that I’m an engineer and I’m interested in opportunities at their company. And I’d also mention that I’d like to learn more about the culture and what it’s like to work there.

If a mutual friend doesn’t send the intro, you can always email the person you wanted to get connected to directly (or send them a request on LinkedIn). If you want to email them directly, there’s a chrome extension called hunter.io that will make it easy to find their email address.

Be open to different opportunities

During the course of your job hunt, you will get random emails and LinkedIn messages about different job opportunities. When you get this type of email, give the company a shot. There’s really no downside. Even if you weren’t initially interested in the company, you might love the people and the culture there.

When I was job hunting a few years ago, a friend mentioned opportunities at Liberty Mutual early in my job search. I didn’t give the opportunity a lot of consideration. I knew I wanted to work in a startup environment – not at a larger company. Boy, was I wrong! I’m really lucky I changed my mind and explored opportunities at Liberty because it ended up being the perfect fit for me. If I didn’t give it a chance, I would have never found out how great it was.

The Interview

Know the format before the technical interview

It’s okay to ask the format of a technical interview. Most of the time, companies will tell you what to expect. If you know the types of questions you should expect in an interview, you’ll be able to practice and prepare for the specific format. It’s a different mindset going in if you’re writing on the whiteboard vs. on a computer.

One of the mistakes I frequently made was that I would try to improve weaknesses from the last technical interview instead of work on what I needed to succeed on the next technical interview. While you need to make sure you’re fixing up your weaknesses, you also need to be prepared for the next interview.

Knowing if pseudo code is okay or if you need to know specific syntax is important. Whiteboarding is a different mindset than writing on a computer. A timed hacker rank challenge is different than exercises on coderpad vs. a take home technical assignment. Just like any mid-term, knowing the format of the test will help you prepare.

Don’t mention your weaknesses

I am a very firm believer that it is the company’s job in technical interviews to assess your technical competencies.

If you feel worse about your front-end experience versus your back-end experience, don’t let them know that. First of all, it’s their job to assess your skills. Second, developers are often harder on themselves than other people. Just because you don’t love your front-end skillsets doesn’t mean other people won’t be envious of what you can do.

Also, don’t make excuses as you code. I’ve seen it happen. I’ve done it in the past. I’ve also heard this mentioned in interview debriefings. If you mention you are not great at something, your interviewers will take your words and mention them later. Even if you are being humble, what you say often becomes “the truth” in technical interviews. Make it hard for them. Don’t speak about your faults. Put your best foot forward. Be confident. Let them know you are competent in all parts of your work, and put the work on them to be able to prove otherwise.

Make sure you are prepared

Research company interview reviews on GlassDoor. Don’t assume the questions will be the same, but you can expect similar questions based on available reviews.

Cracking the Coding Interview Book – This book is fantastic! I highly recommend it if you are interviewing. It has a lot of commonly asked behavioral and technical questions. It helps you brush up on CS fundamentals and commonly asked MVC and OOP questions. If you are interviewing, you must buy this book!

Go through HackerRank challenges – A lot of companies will use tools like HackerRank to decide if they should bring you into the office to give you an in-person interview. If companies are using this, you should use the platform in order to practice. They provide many different options for algorithm, data structure, and other types of challenges. They also have dozens of languages available for you to code in.

Check out InterviewCake. Interview Cake is one of the best kept secrets in programming interviews. If you aren’t great at technical interviews, check out this website. It’s the only resource online that recreates a technical algorithm interview (which you often see when an interviewer asks you to use coderpad). It will have you create an initial solution. It will ask you if you can do better. It will show you how you can do better and how the algorithmic efficiency of your solution can be increased. It will teach you how to ace algorithm interviews. It’s probably the best resource you will find online to help you solve these challenges. Don’t take my word for it, go try their demo and you will see why it’s so great!

Post Interview

Learn from every interview

I had an “interviewing notebook” during my job search. In it, I would write down every term I didn’t fully understand. If I was asked a question and I wasn’t happy with my response, I would write it down. Taking note of your mistakes is the first part in correcting them.

I suggest writing these things down in the middle of an interview. If you don’t feel okay doing that, make sure you open up your notebook as soon as your interview is over, and scribble everything you remember not being able to answer efficiently.

If you don’t know the answer to a question once, that’s okay – it happens. If you fail to answer the same question from multiple interviews, that’s your own fault. Make sure you go back in this notebook when you get home and look up what you didn’t fully understand. Software development is about continuous learning.

Go back to the fundamentals

Depending on the company you are interviewing with, they may want you to know a lot about Big O notation, data structures, and algorithms. This is something self taught developers often struggle with. You can take 2 online classes for free to level up your skills and fully understand these concepts. I highly recommend Steve Skiena’s Algorithms class and Brian Harvey’s Intro to Computer Science class.

Even if you never learned them, CS fundamentals aren’t too tough to learn. I recommend going over teachyourselfcs.com and following their recommendations to fill in knowledge gaps.

Ask for feedback explicitly from your interviewers

You should already be writing down what you think you did wrong in your interviews. However, this isn’t always good enough. You also need to find out what the interviewer’s reasons were for passing on you if you don’t get an offer.

I suggest explicitly asking interviewers why they passed on you. You should ask for feedback from your interviewer. You should mention that you’re always trying to improve, and you need to find out what to focus on. Ask them if they can provide any feedback on your interview or suggestions on what you should focus on as you continue your job search.

Companies don’t really have incentives to give you this feedback, but a few will provide it to you if you explicitly ask. Not all feedback is created equal, but any negative feedback you get from a company is a gift. It tells you exactly what you need to improve. It tells you why you didn’t get the offer. You won’t always get it, but make sure you follow-up and ask at least twice for feedback after an interview.

Read more at my blog
http://ibuildmvps.com

Connect with me
http://twitter.com/cavezza
http://linkedin.com/in/cavezza