DEV Community: Avraam Mavridis

Giving praise

Avraam Mavridis — Sun, 04 Nov 2018 07:56:20 +0000

Just some thoughts on giving praise.

One of the biggest mistakes that you can make as a manager/team-lead/head-of-whatever is to give praise only to a few of the people who worked on a project.

Giving praise to only one or two of the people who worked on something has 2 results:

They who got the praise feel embarrased because they think that everyone else thinks that they claimed credit for the whole work.
People who didn't get praise will be extremely dissapointed.

When you give praise, investigate as much as you would if you were about to criticize someone. Understand who did what, pay attention to details, and give everyone the credit they diserve.

Be as detailed and descriptive as possible. Simply saying "Good job" or "Nice" can have the opposite effect, the people who get the praise may think that you only care about the final result and that you don't care or even do not know how it was achieved.

Instead of saying "Good job", try to be more specific, e.g. "It's great that you did X because it will solve the case Y, and we will not struggle in the future with problem Z".

Try to understand the people to whom you give praise, not everyone feels comfortable getting praise in public, and not everyone appreciates getting praise "only" in private.

Some are made modest by great praise, others insolent. - Friedrich Nietzsche

Implementing backpressure for smoother user experience in low-end devices

Avraam Mavridis — Tue, 30 Oct 2018 10:43:49 +0000

If you are building applications that consume real-time data you may have faced a situation where the component or service that consumes the data cannot keep up with the volume or speed of the produced data. The producer module of the system is emitting data faster than the consumer module of the system can process.

The consumer tries to keep up processing the data by increasing the amount of the system resources it is using (CPU, memory). That can be fine in high-end devices where the system resources are not limited, but in low-end devices, it can lead to battery draining or non-smooth user experience.

PULL VS PUSH STRATEGY

If you have designed your system with a pull strategy where the consumer is asking data from the producer whenever it feels ready to process (or in specified intervals) you can most of the times solve the problem by increasing the interval between two data pulls. Imagine that you have a web application that is sending GET requests to a backend endpoint every 50ms and updates the UI with some fancy animations. There could be a situation where the process that updates the UI is hanging because it is slower than the process that requests and processes the data. In cases like that we can increase the interval e.g. to 200ms, the UI will be less "real-timish" but at least it will be smoother.

setInterval(function(){
  axios.get('some-data-endpoint')
       .then(function(response){
           updateUI(response.data)
        })

}, 200)

If your system is not or cannot be based on a pull strategy, but it needs to operate in a push-based fashion, where the producer is pushing data to the consumer, you have to take a different path to solve the problem. Imagine the scenario where your web app is using websockets, where the server is pushing to the UI real-time events (e.g. financial transactions).

socket.on('message', updateUI);

In these situations, the way to solve the problem is usually by establishing a backpressure mechanism.

BACKPRESSURE

Reactive Manifesto has a better definition of backpressure than what I could probably write:

When one component is struggling to keep-up, the system as a whole needs to respond in a sensible way. It is unacceptable for the component under stress to fail catastrophically or to drop messages in an uncontrolled fashion. Since it can’t cope and it can’t fail it should communicate the fact that it is under stress to upstream components and so get them to reduce the load. This back-pressure is an important feedback mechanism that allows systems to gracefully respond to load rather than collapse under it. The back-pressure may cascade all the way up to the user, at which point responsiveness may degrade, but this mechanism will ensure that the system is resilient under load, and will provide information that may allow the system itself to apply other resources to help distribute the load.

There are two ways to achieve backpressure and we have to choose based on the needs of our application, the loss-less strategy, and the lossy strategy.

LOSS-LESS VS LOSSY

In the lossy strategy, we can skip values until a certain amount of time has been passed or after the occurrence of an event (e.g. mouse click). In this case, we elaborate only on the most recent value(s) and we can accept the fact that potentially we could lose some values. This usually is fair when the data is not critical.

Loss-less Strategy	Lossy Strategy
Values are discarded and never at the Observer.	Values are stacked and emitted in batches.
Example: Mouse positions sampled over a period of time	Example: Real-time data from a socket using a buffer operator.
The app is using the latest position and ignores the previous ones.	The app is processing the data in batches

Example

To demonstrate how we can implement backpressure I created a small example using RxJS and Websockets. Our dummy app is connecting with a remote socket server that is pushing data related to cryptocurrency prices and update the UI. First lets create a stream:

function getStream(){
  const socket = io.connect('streamer.cryptocompare.com');
  const subscription = ['ID-1', 'ID-2'];
  socket.emit('SubAdd', { subs: subscription });

  return Rx.Observable.create(function(observer){
    socket.on('m', function(data){
      observer.next(data);
    })
  })
}

Then I created a simple react component that subscribes to the stream and updates the UI whenever a message arrives:

class App extends Component {
  state = {
    messages: []
  };

  componentDidMount() {
    const stream$ = getStream();
    stream$.subscribe(m => {
      this.setState({
        messages: this
          .state
          .messages
          .concat(m)
      })
    })
  }

  ...
  ...

  render() {
    return (
      <ul>
        {
         this
          .state
          .messages
          .map(msg => <li key={msg.id}>{msg.label}</li>)
        }
      </ul>
    );
  }
}

I run the application and started measuring its performance. As you can see from the following gif even in my high-end device, when I try to scroll the frame rate drops significantly and the UI experience is terrible:

USING BACKPRESSURE

There are various operators that can help us achieve backpressure

sample()
throttleFirst()
buffer()
window()

Let’s see a few of them using Marble diagrams.

SAMPLING

In sampling, we glance at the sequence of the emitted values periodically and we use the last emitted value at each period:

Sampling is a lossy backpressure strategy.

THROTTLEFIRST

The throttleFirst is the same as sampling but instead of using the last emitted value, we use the first value that has been emitted in a specified period:

throttleFirst is a lossy backpressure strategy.

BUFFER

With buffer we can create a batch of emitted items and then the consumer can decide whether to process only one particular item from each collection or some combination of those items.

buffer is a loss-less backpressure strategy.

WINDOW

With window we can specify how many items we want to collect before closing and emitting the batch.

window is a loss-less Strategy backpressure strategy.

Example applying backpressure

To apply backpressure in our example the only thing we have to do is to add sampling using the sample operator:

class App extends Component {
  state = {
    messages: []
  };

  componentDidMount() {
    const stream$ = getStream();
    stream$.sample(500).subscribe(m => {
      this.setState({
        messages: this
          .state
          .messages
          .concat(m)
      })
    })
  }

  render() {
    return (
      <ul>
        {
         this
          .state
          .messages
          .map(msg => <li key={msg.id}>{msg.label}</li>)
        }
      </ul>

    );
  }
}

Summary

Backpressure is a useful technique to achieve smooth user experiences, even for the users that do not have powerful devices. Unfortunately most of the browsers do not expose the hardware characteristics of the user’s machine (probably for privacy/security reasons), so as developers we have to either do browser sniffing and then guess the device’s capabilities, or try to find the sweet spot that will offer enjoyable experience for all of our users.

Codetip - Javascript: Hide Dependency to a Data Structure

Avraam Mavridis — Sun, 28 Oct 2018 14:00:35 +0000

Many times we encounter situations where our code depends on a complicated data structure or a data structure that has implicit semantics. For example, let’s say we create a chart and the data that we have to use is a response from a server (we can’t change the structure of the response). The response from the server looks like this:

[
 ["2018-12-02", 1000], 
 ["2018-11-02", 900], 
 ["2018-10-02", 200], 
 ["2018-09-02", 300]
]

This structure has an implicit meaning, it is an array of arrays, each of which has two values, the first represents a date and the second one a value. The naive approach is to use this structure directly in our code, like:

class Chart {
  constructor(data){
    this.data = data;
  }

  createDomains(){
    x.domain(d3.extent(this.data, d => d[0])); // date
    y.domain(d3.extent(this.data, d => d[1])); // value
  }

  createLine(){
    d3.line()
      .x(d => d[0]) // date 
      .y(d => d[1]); // value
  }

  formatDate(){
    this.data.forEach(d => {
      d[0] = parseTime(d[0]); // date
    });
  }
}

The problem with this approach is that, if the server decides to change the order of the values, or introduces a new one in the first or second place of the array, our code we break, let’s say the structure changes to look like:

[
 ["Dinos", "2018-12-02", 1000], 
 ["Nikos", "2018-11-02", 900], 
 ["Petros", "2018-10-02", 200], 
 ["Giannis", "2018-09-02",  300]
]

Now our class is broken, every single method of it is broken. We have to update every method to fix the problem. A better approach would be to not depend on the structure of the response.

class Chart {
  constructor(data){
    this.data = data.map(dataPoint => ({
      date: dataPoint[0],
      value: dataPoint[1],
    }));
  }

  createDomains(){
    x.domain(d3.extent(this.data, d => d.date));
    y.domain(d3.extent(this.data, d => d.value));
  }

  createLine(){
    d3.line()
      .x(d => d.date)
      .y(d => d.value)
      .values(this.data) 
  }

  formatDate(){
    this.data.forEach(d => {
      d.date = parseTime(d.date);
    });
  }
}

If the server decides to change the passed data structure, we will have to update our code only in a single place, the constructor, leaving every other method untouched.

Codetip - Javascript: Remove argument-order dependency and provide defaults

Avraam Mavridis — Sun, 28 Oct 2018 13:57:17 +0000

Argument order in function signature is a common source of bugs and frustration. Imagine you have the following Vehicle class, its constructor accepts values to instantiate an object. Passing the values in the wrong order can easily lead to bugs that are not so easy to catch.

class Vehicle {
  constructor(speed, weight, power, color, brand){
    this.speed = speed;
    this.weight = weight;
    this.power = power;
    this.color = color;
    this.brand = brand;
  }
}

Obviously we can avoid the order dependency by passing an object to the function.

class Vehicle {
  constructor(args = {}){
    Object.keys(args)
      .forEach(argument => this[argument] = args[argument]);
  }
}

There is a problem though, what if we want our constructor to have some default values in case these are not provided? In the first example, we would write our class like that:

class Vehicle {
  constructor(speed = 100, weight = 1500, power = 111, color = "red", brand = "Kia"){
    this.speed = speed;
    this.weight = weight;
    this.power = power;
    this.color = color;
    this.brand = brand;
  }
}

To provide defaults in case we use an object as a single parameter, we can create a defaults property that returns our defaults, and merge the passed args object with our defaults in the constructor. The defaults property acts also as a form of documentation for the properties our class expects.

class Vehicle {
  constructor(args = {}){
    args = { ...this.defaults, ...args };
    Object.keys(args)
      .forEach(argument => this[argument] = args[argument]);
  }

  get defaults(){
    return {
      speed: 100,
      power: 1000
    }
  }
}

Subclasses can provide their own defaults

class Car extends Vehicle {
  get defaults(){
    return {
      speed: 150,
    }
  }
}

Or even extend the defaults provided by the base class

class Car extends Vehicle {
  get defaults(){
    return {
      ...Vehicle.prototype.defaults,
      speed: 150,
    }
  }
}

My first React hook

Avraam Mavridis — Sat, 27 Oct 2018 04:46:12 +0000

This is not an introduction to hooks, or any kind of tip or best practices, at the end hooks were just announced, so we have to play around with them and wait to see how the community embrace them, and the best practices that will come up. This is just my experience of implementing a hook.

I wanted to create a hook that will use the Intersection Observer API, to track the visibility of a functional component. Whenever the visibility change (component on viewport or not) I want the hook to update the state of the component.

I am gonna call my hook useVisibility.

Intersection Observer needs access to the DOM node it's gonna observer:

var target = document.querySelector('#listItem');
observer.observe(target);

So useRef seems the right hook to create a reference to our component's markup

function HelloComponent(){
  const nodeRef = useRef(null);

  return (
    <div className="App" ref={nodeRef}>
      <h1>Hello</h1>
    </div>
  );
}

Apart from the node reference, Intersection Observer accepts some options, this can be the second parameter of our hook, so the signature of it can be:

  const visibility = useVisibility(nodeRef, options);

Let's write the actual hook now, we will need the useState hook of React to track the visibility state

function useVisibility(node, options = {}) {
  const [ visible, setVisibilty ] = useState({});
  ...

Then we are gonna create an instance of the Intersection Observer passing a callback and the options.

const observer = new IntersectionObserver(handleObserverUpdate, options);

To start calling the callback we need to tell the observer to start observing our node, since this is a browser API "outside of react world", we are gonna use the useEffect hook provided by React.

  useEffect(() => {
    if (node.current) {
      observer.observe(node.current);
    }
  });

Our code has a memory leak though, we need to provide a way to cleanup, for this reason we are returning a callback that when is called tells our observer to stop watching the node.

  useEffect(() => {
    if (node.current) {
      observer.observe(node.current);
    }

    return function cleanup() {
      observer.unobserve(node.current);
    };
  });

Finally our handler will look like this:

  const isIntersecting = useRef();

  const handleObserverUpdate = (entries) => {
    const ent = entries[0];

    if (isIntersecting.current !== ent.isIntersecting) {
      setVisibilty(ent);
      isIntersecting.current = ent.isIntersecting;
    }
  };

Now, you may wonder why I am using const isIntersecting = useRef() since this is not a DOM node.

As the docs state:

Note that useRef() is useful for more than the ref attribute. It’s handy for keeping any mutable value around similar to how you’d use instance fields in classes.

I wanted a ref attribute that persist for the full lifetime of the component.

Summarising, personally I found the new API very simple and super useful, and I am very excited with what the solutions and best practices the community come up in the next months.

To be honest though, testing was not as easy as expected, mainly because of the need to mock a browser API like this, and not because of the hook API. Most testing frameworks come with utils to simulate clicks, input changes etc, but some APIs need manual mocking and depending on their complexity that can be tricky.

You can find the hook here

AvraamMavridis / react-intersection-visible-hook

React Hook to track the visibility of a functional component

react-intersection-visible-hook

React hook to track the visibility of a functional component based on IntersectionVisible Observer.

In the following example we changed the background color of the body depending on the visibility of the blue box.

Demo and tests are coming

import useVisibility from 'react-intersection-visible-hook'

How to use it

function App() {
  const nodeRef = useRef(null);
  const visibility = useVisibility(nodeRef);
  return (
    <div className="App" ref={nodeRef}>
      <h1>Hello</h1>
    </div>
  );
}

With options

const options = {
  root: document.querySelector('#scrollArea'),
  rootMargin: '0px',
  threshold: 1.0
}
function App() {
  const nodeRef = useRef(null);
  const visibility = useVisibility(nodeRef, options);
  return (
    <div className="App"

…

View on GitHub

Implementing feature toggles for a React App using Webpack

Avraam Mavridis — Thu, 25 Oct 2018 14:39:23 +0000

Feature switches/toggles are an important technique that can help us deploy code in various environments under different conditions without blocking other developers in the team (or other teams) from releasing their features. Martin Fowler has an extensive article on the topic, I won't focus on the theoretical part of it, I would like to show an implementation of feature flags in a react project.

Let's assume that we are working on a React Project where we have 4 environments,

Development (local development)
Testing (where our tests are running aka NODE_ENV=test)
Staging (Production like environment, minification bundling etc)
Production

and let's assume that we have a super experimental component that we would like to display on our Staging environment so we can QA it, but not on production.

class ExperimentalButton extends Component {

  render() {
    return <Button.Primary {...this.props} />;
  }
}

Webpack has a plugin that can help us create feature flags, its called DefinePlugin

new webpack.DefinePlugin({
  'process.env': {
    SHOW_EXPERIMENTAL_BUTTON: true
  }
});

Usually in our projects we have webpack.config.dev.js and webpack.config.production.js, but not a config for staging, since we want the code on staging and production to be identical usually we deploy the production build there. Also we don't pass our source code through Webpack before running tests. So how would we differentiate between staging/production/development but avoid creating a webpack.config.staging.js?

In my case I created a featureToggles.json which looks like this:

{
  "test": {
    "showExperimentalButton": true,
  },
  "development": {
    "showExperimentalButton": true,
  },
  "staging": {
    "showExperimentalButton": true,
  },
  "production": {
    "showExperimentalButton": false,
  }
}

To differentiate among stating/production/development in my package.json I pass a flag to the script

    "build:production": "npm run build",
    "build:staging": "npm run build -- --staging",
    "build:development": "npm run build -- --development",

In my webpack.config.js (shared configuration options for every environment) I do:

const featureSwitches = require('./featureSwitches.json');

let features_env = process.argv[2] === '--staging' ? 'staging' : 'production';
features_env = process.argv[2] === '--development' ? 'development' : features_env;

...
...

new webpack.DefinePlugin({
  'process.env': {
    ...featureSwitches[features_env]
  }
});

To display/hide our component we will do something like

{ process.env.showExperimentalButton ? <ExperimentalButton /> : null }

(Or we can go a step further and create a wrapper component <FeatureToggle feature='showExperimentalButton'>.)

There is a problem though, the previous is not working on the testing environment, since the code is not being passed through Webpack. So we are unable to write unit tests for the component. First we need to tell Jest to setup a few things before running the tests, we can do that with the setupTestFrameworkScriptFile option
and create a jest.init.js.

setupTestFrameworkScriptFile: '<rootDir>/jest.init.js',

In our jest.init.js file we will do:

const featureSwitches = require('./config/featureSwitches');


Object.keys(featureSwitches.test).forEach((key) => {
  process.env[key] = featureSwitches.test[key];
});

Now we are able to run unit tests for our experimental component.

CodeTip - Javascript: Pseudomandatory parameters in es6 functions

Avraam Mavridis — Thu, 25 Oct 2018 07:20:14 +0000

In many programming languages, the parameters of a function are by default mandatory and the developer has to explicitly define that a parameter is optional. In Javascript, every parameter is optional, but we can enforce this behavior without messing with the actual body of a function, taking advantage of es6’s feature of default values for parameters.

const _err = function(message) {
  throw new Error(message);
}

const getSum = (a = _err('a is not defined'), b = _err('b is not defined')) => a + b;

getSum(10); // throws Error b is not defined

_err is a function that immediately throws an Error. If no value is passed for one of the parameters, the default value is going to be used, err will be called and an Error will be thrown. You can see more examples for the default parameters feature on Mozilla’s Developer Network.

Null Object Pattern

Avraam Mavridis — Thu, 25 Oct 2018 05:13:27 +0000

Many times functions accept object references that can be null, and we tend to add if statements to treat the special case where null is passed to a function, and either provide a default response or do nothing. In the following example our calculateSpeed function expects an object that has a getSpeed function. In Javascript we will have to do something like:

class Car {
  getSpeed(){
    return 100;
  }
}


const calculateSpeed = function(vehicle){
  if(vehicle && typeof vehicle.getSpeed === 'function'){
    return vehicle.getSpeed();
  } else {
    return 50;
  }
}

const car1 = new Car();

console.log(calculateSpeed(car1)); // 100
console.log(calculateSpeed()); // 50

But there is a better way to achieve that. Using the Null Object Pattern we can create a class that acts as vehicle, lets call it DefaultMovable.

class DefaultMovable {
  getSpeed(){
    return 50;
  }
}

Our DefaultMovable class provides the default functionality (aka the else in our previous code snippet), that way we can avoid the if/else statement.

class Car {
  getSpeed(){
    return 100;
  }
}

class DefaultMovable {
  getSpeed(){
    return 50;
  }
}

const calculateSpeed = function(vehicle = new DefaultMovable()){
  return vehicle.getSpeed();
}

const car1 = new Car();

console.log(calculateSpeed(car1)); // 100
console.log(calculateSpeed()); // 50

The UML diagram of this pattern will look like this:

The same example in Ruby would look like:

class Car
  def get_speed
    100
  end
end

class DefaultMovable
  def get_speed
    50
  end
end


def getSpeed(vehicle = DefaultMovable.new)
  vehicle.get_speed();
end

This is just a pattern and as every pattern it has its pros and cons, apply it thoughtfully based on your use case. (The example is fictional for the shake of demonstrating the pattern)

CodeTip - Ruby: Compare class instances

Avraam Mavridis — Thu, 25 Oct 2018 05:07:48 +0000

In the previous post I wrote about how to compare objects in Javascript. In Ruby we can do the same using the Comparable module. We include the comparable module in our class and we define a pseudooperator-method <=>. Let’s say we have again a Car class that looks like this:

class Car
  attr :speed

  def initialize(speed)
    @speed = speed
  end
end

And now let’s make their instances comparable by including the Comparable module and defining the <=> pseudooperator.

class Car
  include Comparable
  attr :speed

  def <=>(other)
    self.speed <=> other.speed
  end

  def initialize(speed)
    @speed = speed
  end
end

car1 = Car.new(100)
car2 = Car.new(120)
car3 = Car.new(90)

p car2 > car1 # true
p car3 > car2 # false


cars = [car1, car2, car3]

p cars.sort() # [#<Car:0x000055aec8add4b0 @speed=90>, #<Car:0x000055aec8add500 @speed=100>, #<Car:0x000055aec8add4d8 @speed=120>]

CodeTip - Javascript: Compare class instances

Avraam Mavridis — Wed, 24 Oct 2018 16:48:16 +0000

Many times we are in situations we want to compare instances of a class, aka objects, for example in case you develop a game and you want to compare instances of a gameobject, e.g. Car:

class Car {
  constructor(speed){
    this.speed = speed
  }
}

Let's say we want to compare instances of a car (or sort/filter an array of them). Obviously we can do:

const car1 = new Car(100)
const car2 = new Car(120)
const car3 = new Car(90)

console.log(car2.speed > car1.speed) // true

const sorted = [car1, car2, car3].sort((a,b) => {
  return a.speed - b.speed;
});

This works perfectly fine but we can do better, so we don’t have to type .speed every time we want to compare two cars, or sort/filter an array of them. We can define a valueOf method in the Car class, the method returns the “value” of the instance.

class Car {
  constructor(speed){
    this.speed = speed
  }

  valueOf(){
    return this.speed;
  }
}


const car1 = new Car(100)
const car2 = new Car(120)
const car3 = new Car(90)

console.log(car2 > car1) // true

CodeTip - Ruby: Provide ways to iterate over collections

Avraam Mavridis — Wed, 24 Oct 2018 06:43:09 +0000

Sometimes we have classes that represent collections, for example a class Group can represent a collection of members

class Group
  def initialize(members)
    @members = members.dup
  end
end

When we want to iterate over the collection’s members we have to expose them through attr_reader

class Group
  attr_reader :members

  def initialize(members)
    @members = members.dup
  end
end

group1 = Group.new(["Nick", "Ana", "Petros"])

group1.members.each { |x| p |x| }

The problem with this approach is that the consumers of our collection have to know that we named our variable “members” and use it to iterate. If we ever rename this variable, the consumers of our collection have to rename their call as well. Moreover, we can’t control the order of the enumeration. What can we do to fix that?

We can make our collection an Enumerable, and define an “each” method

class Group
  include Enumerable

  def initialize(members)
    @members = members.dup
  end

  def iterate_members_alphabeticaly
    ite = @members.dup.sort
    while k = ite.shift()
      yield k
    end
  end

  def iterate_members_by_name_length
    ite = @members.dup.sort_by { |x| x.size }
    while k = ite.shift()
      yield k
    end
  end

  def each(&block)
    enum_for(:iterate_members_by_name_length).each(&block)
  end
end


group1 = Group.new(["Nick", "Petros", "Ana"])

group1.each {|x| p x }

That way we don’t expose the name of the variable and we can control the order of the enumeration, e.g. in the previous example we can change the :iterate_members_by_name_length with :iterate_members_alphabeticaly

def each(&block)
  enum_for(:iterate_members_by_name_length).each(&block)
end