Forem: Achilles Moraites

Github actions tweaks

Achilles Moraites — Thu, 10 Jun 2021 19:54:41 +0000

Here there are some cool tricks you can do to improve your Github Actions.

Caching your packages

How many times you have re-installed all of your packages in your actions even when no packages were changed?
This is not only time consuming but it can actually cost you more money as Github actions are charged based on the time they actually run;
you can have a look here in case you are interested 😉

How

To cache our modules we will use the actions/cache@v2 action

Here is an example of caching npm dependencies for Linux/MacOS

- name: Cache node_modules 📦
  uses: actions/cache@v2
  with:
    path: ~/.npm
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-node-

Here you can see it in a Github Action used for deploying my svelte-kit powered blog to gh-pages 🚀

Create strings based on env variables

There are times where you need to be able to create a string based on env variables.
The most common case is when you want to create a path using one or more env variables;

How

name: paths-printer 🦄

env:
  BASE_URL: "https://example.com/"
jobs:
  print-stuff:
    runs-on: ubuntu-latest
    steps:
      - name: Create paths from env variables
        # this outputs "IMAGES_PATH: https://example.com/assets/img/"
        run:  echo  "IMAGES_PATH: ${env.IMAGES_PATH}"
        env:
          IMAGES_PATH: "${{ env.BASE_URL }}assets/img/"

Use a custom npm config

This is very handly when you are working with private packages 📦
The idea is to store your PAT TOKEN for accessing your packages in your repository secrets and then use it on a custom npm config file.

📝Note that we can just use the default .npmrc but it is a good idea to keep the npm config for your github actions separated.

How

In order for it to work we need to:

an npm config file 🦄
- includes the configuration for our private github packages
- we will take the PAT TOKEN from an env variable
- we can name it anything that we want
- place it in the project root folder
set our action to use our npm config file ✨
create a PAT TOKEN
place the PAT TOKEN in our repository secrets

Lets have a look at a case where we are using private github packages

Create the npm config file

Create a file named .ci.npmrc in the root folder of your project and place the following contents:

@your-scope:registry=https://npm.pkg.github.com
//npm.pkg.github.com/:_authToken=${NODE_AUTH_TOKEN}

💡 Remember to replace "@your-scope" with your scope

Set the action to use our custom npm config file

- name: Install dependencies ✨
  run: npm ci
  env:
    NPM_CONFIG_USERCONFIG: .ci.npmrc
    NODE_AUTH_TOKEN: ${{ secrets.PAT_TOKEN }}

Create your PAT TOKEN Follow the instructions here When you are on the step 7 permissions and scopes:

make sure to select the "write:packages" option!
the "read:packages" is enabled as well
Continue to the next steps and keep your PAT TOKEN ready!

Place the PAT TOKEN to your repo secrets Go to your repository on github:
1. Click on "⚙️settings" tab
2. Select "Secrets"
3. Click on "New repository secret"
4. Set the "name" to be "PAT_TOKEN"
5. Paste your token in the "value"
6. Select "Add secret"

Summary 👨🏻‍💻

We have explored ways to improve the performance of our github actions using caching.

Then we explored how we can create strings dynamically from env variables and finnaly we had a look in configuring our npm config for using private github packages in a secure and scalable way 😉.

Happy coding 😄 !!!

(The original post was published here)

Optimizing moment-timezone using webpack

Achilles Moraites — Sun, 20 Sep 2020 09:21:36 +0000

moment-timezone is an awesome tool to have when working with different time-zones.

While the tool is great it also has lots of data that we might never use, bloating the size of our applications.

We can do better!

But first, some facts

To optimize an application we need to know some things about it.

Imagine that we have an application that is providing a search functionality for scientific articles.

Each article has information about it's creation and last modification dates.
The oldest article is from 1990.
Our application is being used by universities in Europe and Australia only.

So we need the following timezone data

time-zones from Europe and Australia only
year range from 1990 - 2020 (present year)

Optimizing based on our needs

Now that we know what we need, we can start the optimization.

We will use a webpack plugin called moment-timezone-data-webpack-plugin to keep only the data we need from our application.

Install the plugin

npm i -D moment-timezone-data-webpack-plugin

Adding the plugin to webpack

For simplicity I will only show the plugin related configuration in the webpack file.

const MomentTimezoneDataPlugin = require('moment-timezone-data-webpack-plugin');

module.exports = {
  plugins: [
    new MomentTimezoneDataPlugin({
        matchZones: [/^Europe/, '/^Australia/'],
        startYear: 1990,
        endYear: 2020,
    }),
  ]
};

And that's it :)

Now our application will have only the timezone data that we actually need!

Happy coding! :)

Design Patterns - Basic Iterator

Achilles Moraites — Fri, 22 May 2020 17:54:32 +0000

Among the most common things in a collection of items is the ability to iterate through the collection.

In Java for example there are data structures that are allowing us to create collections for primitive data or our custom classes.

Here are some : ArrayList<T>, LinkedList<T> , HashSet<T> and others...

The above have something in common , all are implementing the Interfaces : Collection and Iterable.

This can give us the abillity to make our own classes iterable :)

In this article we will explore how to do it.

How it works

Below there is a simplified UML diagram illustrating the ArrayList :

The above relationships are allowing us to use this magic:

for(String s: stringList){
     // do something with s
      System.out.print(s);
}

The above is a convenient way to write a foreach loop in Java, but the language it self translates it to:

Iterator<String> si = stringList.iterator();

while(si.hasNext()){
   String s = si.getNext();
   // do something with s
    System.out.print(s);
}

Now armed with this knowledge we can go beyond the default behaviors of the build in collections and can customize it for our own needs!

Lets play with a project!

Project : CarPartsStore

get the source code here

Here we will illustrate the customized behavior by exploring a Store that sells car parts, in this code-base we have the Warehouse class that contains a List of CarPart .

What we do here: We will use the basic Iterator Pattern to iterate through our Warehouse class for CarPart .

We will make something like the following to work:

for(CarPart part: Warehouse){
  // do interesting stuff ...
}

by default the above is not working as our warehouse has a field of ArrayList , but having the new awesome Iterator powers we can can do it !

in our Warehouse class we have:

public class Warehouse implements Iterable<CarPart> {
  private List<CarPart> carPartList;
  private String location;
...

In our Warehouse class we add the implements Iterable :

public class Warehouse implements Iterable<CarPart>

notice that we used the CarPart type , as we want to iterate through a collection of CarPart.

also we will implement the following in our Warehouse class :

@Override 
public Iterator<CarPart> iterator() {
    return carPartList.iterator();
}

Now when we try to iterate through our warehouse we iterate through the carPartList !

// Now this magic is available :)
for(CarPart part: Warehouse){
  // do interesting stuff ...
}

Congratulations ! now you have learned how to take iteration to your hands!

Feel free to experiment with the code!!!

Happy coding!!!

the original article was posted here

Types of Modules in Angular

Achilles Moraites — Sun, 10 May 2020 13:23:12 +0000

Crafting high quality Angular apps requires to have knowledge of how to use the different types of modules to ensure readability, performance and scalability.

By setting up your project to use each module type properly you will have better control over your project to add more advanced features such as Lazy Loading and a more organized structure to work with.

We have 3 types of modules:

Feature modules
Core Module
Shared Module

Feature Modules

those are the modules that encapsulate a specific feature at a logic level, for example you have a dashboard page that allows the users to see their projects.

The dashboard module will have everything that is needed to allow a user to see their projects:

components
services
pipes
directives

In general feature specific functionality is included in the module.

If we need to use some common functionality in our Feature Modules we import the Shared Module in the Modules that needs it.

We will talk more about shared functionality later.

// feature module example
import { NgModule } from '@angular/core';
import { SharedModule } from '../shared/SharedModule';

import { DashboardComponent } from './dashboard/dashboard.component';
import { ProjectComponent } from './project/project.component';

@NgModule({
  imports: [
    NgModule,
    SharedModule
  ],
  declarations: [ DashboardComponent, ProjectComponent ]
})
export class DashboardModule { }

Core Module

Here we include functionality that will be used only ONCE!

The Core module is used ONLY in the root (app) Module!

Common services are placed in the Core Module to ensure we have only a single instance of the services to avoid unexpected behaviors.

In this type of module we also place components that are used only ONCE for example the NavBar and the Footer components.

// core module example
import { NgModule, Optional, SkipSelf } from '@angular/core';

import { ApiService } from './services/api.service';

@NgModule({
  providers: [ ApiService ]
})
export class CoreModule {
   // do not allow to be used more than ONCE!!!
  constructor(@Optional() @SkipSelf() parent: CoreModule) {
    if (parent) {
      throw new Error(
        'Import CoreModule in the root module only!!!'
      );
    }
  }
}

Shared Module

This is the most missunderstooded kind of Module!

The purpose of the SharedModule is to make available commonly used:

components
directives
pipes

We use the SharedModule in the feature modules to make common functionality available.

We also make sure to have only one Shared Module.

We avoid placing services here!

// shared module example
import { CommonModule } from '@angular/common';
import { NgModule } from '@angular/core';

import { CustomerComponent } from './components/customer/customer.component';
import { PercentagePipe } from './pipes/percentage/percentange.pipe';
import { CustomerStyleDirective } from './directives/customer-style/customer-style.directive';

@NgModule({
  imports: [ CommonModule ],
  exports: [
    CommonModule,
    CustomerComponent,
    PercentagePipe,
    CustomerStyleDirective 
  ],
  declarations: [ CustomerComponent, CustomerStyleDirective, PercentagePipe ]
})
export class SharedModule {}

This was a brief introduction to the 3 most common Modules types used in Angular Applications.

Happy coding :)

Advanced Angular Testing using Jasmine

Achilles Moraites — Sat, 21 Mar 2020 09:18:07 +0000

When testing our apps there are times when we need to control things that are beyond our control, like the window object.
One common scenario is when we need to test our code against browser specific APIs.

If you are looking how to upgrade your testing skills this is the article you have been looking for!

Show me the code

// history.component.ts
import { Component, OnInit } from '@angular/core';

@Component({
  selector: 'app-history',
  templateUrl: './history.component.html',
  styleUrls: ['./history.component.css']
})
export class HistoryComponent implements OnInit {

  constructor() { }

  ngOnInit() {
  }

  goBack() {
    if (window.history.length === 1) {
      console.log('length 1');
    } else {
      window.history.back();
    }
  }

  saveFile() {
    const blob = new Blob([''], {
      type: 'text/html'
    });
    // IE
    if (window.navigator && window.navigator.msSaveOrOpenBlob) {
      window.navigator.msSaveOrOpenBlob(blob, 'file.txt');
    } else {
      console.log('custom handling');
    }
  }

}

Now lets test the `goBack()` method

As you know already the window.history is read only.
We need to test two cases:

history.length == 1
history.length > 1

in our history.component.spec.ts
we use the spyOnProperty to mock the window.history.length to be able to test our both cases:

  it('should execute "goBack" as expected when history === 1', () => {
    // spy on console.log()
    spyOn(console, 'log');
    // here we mock the history length to be 1
    spyOnProperty(window.history, 'length', 'get').and.returnValue(1);
    component.goBack();

    expect(console.log).toHaveBeenCalledWith('length 1');
  });

  it('should execute "goBack" as expected when history > 1', () => {
    // spy on window.history.back()
    spyOn(window.history, 'back');
    // here we mock the history length to be 2
    spyOnProperty(window.history, 'length', 'get').and.returnValue(2);
    component.goBack();

    expect(window.history.back).toHaveBeenCalled();
  });

that was easy :)

Now lets tackle a more interesting case, what about testing a browser specific api?

Testing browser specific APIs

Now in the saveFile() method we are using a browser specific API, here things are getting more interesting.

The window.navigator.msSaveOrOpenBlob is available only on IE,
on other supported browsers we have a different implementation.

Let's dive to our test code!

 it('should execute "saveFile" as expected on IE', () => {
    // create a mock navigator
    const mockNavigator = jasmine.createSpyObj(['msSaveOrOpenBlob']);
    // here we use the mockNavigator to simulate IE
    spyOnProperty(window, 'navigator', 'get').and.returnValue(mockNavigator);
    component.saveFile();

    // verify that method has been called :)
    expect(mockNavigator.msSaveOrOpenBlob).toHaveBeenCalled();
  });

  it('should execute "saveFile" as expected on browsers other than IE', () => {
    // spy on console.log()
    spyOn(console, 'log');
    // create a mock navigator
    const mockNavigator = jasmine.createSpyObj(['']);
    // here we use the mockNavigator to simulate behavior
    spyOnProperty(window, 'navigator', 'get').and.returnValue(mockNavigator);
    component.saveFile();

    // verify that method has been called :)
    expect(console.log).toHaveBeenCalledWith('custom handling');
  });

Here we mocked the window.navigator to be able to simulate the behavior on both cases!

Summary

Today we learned about mocking the window object to be able to do tests against browser specific APIs.
By using this technique you will be able to mock anything you need to test your code.

I hope you enjoyed it,
Happy coding :)

Component Inheritance

Achilles Moraites — Sun, 08 Mar 2020 19:49:17 +0000

About

Component inheritance can be useful when you
have duplicated/shared code between your components.

Think about having a situation where you have 3 components
that share a theme @Input()

This could be the case where you want to have your components to adapt based on a provided theme.

Why

When you have 2-3 components with shared functionality
you might say "well why to bother with inheritance?".

And in the most common cases that's okay, you don't need to.

But by using inheritance you do more than just to avoid to type the shared functionality between your components.

The benefit of inheritance is when we have shared functionality in many components!

How

Using component inheritance is simple, you need:

A Base component
The Component/s to extend the Base component

A simple example

Here we will use only one component to extend the Base component but the same process applies to no matter how many components we are going to use.

Base component

// base.component.ts
//....
@Component({
selector: 'my-base',
template: '' // notice that the template is empty!
})
export class BaseComponent implements OnInit {
    @Input() theme: string;

    constructor() {}

    ngOnInit() {}
}

ThemedInput component

By extending the Base component the ThemedInput has the theme input!

Anything added / updated in the Base component will be reflected here too!

// themed-input.component.ts
//....
@Component({
selector: 'my-themed-input',
templateUrl: './themed-input-component.html'.
styleUrls: ['./themed-input-component.scss']
})
export class ThemedInputComponent extends BaseComponent implements OnInit {

    constructor() {
        super();
    }

    ngOnInit() {}
}

Changing/Updating shared functionality

Having a base component with the shared functionality you can now change/update the shared functionality in one place instead of doing it in every component that exists or will be created in the future!

A good scenario would be when you decide to use a service that is common to all the components to share state.

Imagine that one day you need to switch to NgRx:

Case 1 - You are using inheritance: all you need to do is to update the base component to start using it.
Case 2 - You are NOT using inheritance: oh poor soul... you will need to go to all of the components and you will need to update the code for each one of them!

I believe the first Case is faster, simpler and less error prone ;)

Adding new shared functionality becomes simple!

Testing shared code

Testing the shared functionality is simpler, all we need to do is to test the base class.

This way we avoid having to write tests that are actually testing the same shared code across components.

Summary

Using the right tool for the job is important, here we explored using component inheritance to:

simplify the usage of shared component code
allow for easier future change / update
optimizing the testing of our shared code

Inheritance is powerful yet keep in mind that to use it only when it makes sense.

Most of the times composition does the trick!

Happy coding!!!

Testable Code 101

Achilles Moraites — Tue, 04 Feb 2020 21:16:30 +0000

What

Testable code is code that is easy to test.
Having testable code improves our codebase making it easier to add features, maintain or even scale it.

Why?

Testable code is an investment that will benefit your team and project in various ways, it can even make your grumpy project manager happy.

Testable code is more organized and will put us in the process of splitting our code's functionality to small, manageable and reusable components leading to more robust designs.
Refactoring your code is easier and you can verify on the spot if something is wrong thus saving you precious time and effort.
Writing your tests is faster and simpler.

Testable code has the following properties:

Controllability : Is the extend of our ability to execute the code under test with the states and parameters we care about.
Observability: The behaviors of our code that can be verified.
Isolateability: Failures can be isolated from each other.
Automatability: How able we are to automate our tests.

How

Examples of code being improved

Controllability:

Our Function checks is it is Monday: if it is Monday returns true otherwise false.

This code is not testable : we have no control over the date object.

The CONTROLABILITY attribute is missing!

This function will return true once a week and is not reliable for testing!!

function isMonday():boolean {
  let date = new Date();
  return date.getDay() === 1;
}

Now we have refactored our code to be more controllable : we now pass a date object.

We can create reliable test cases for this function because we have control over the date object used in the function.

function isMonday(date:Date):boolean {
    return date.getDay() === 1;
}

Observabillity:

The setName method is not observable, so we can't verify that the name is assigned.

We have made the name field public and this is a BAD IDEA to be able to test our method

class Student{
    public name: string = "";

     setName(name:string){
         this.name = name;
     }

}

So in our test suite we have something like:

 let student = new Student().setName('Patrick');
 expect(student.name).to.equal('Patrick');

we use the name field. There has to be a better way!

We refactored our code and now we can verify that the name is assigned while our name field remains private!

class Student{
    private name: string = "";

     setName(name:string):string{
         this.name = name;
         return this.name;
     }
}

Now we can test the method like that:

 let student = new Student();
 expect(student.setName('Patrick')).to.equal('Patrick');

Isoletabillity:

Isoletabillity can be achieved by splitting large methods to smaller components enabling us to better trace where a fault is located.

If you have a method of 80+ lines of code there are various things that are going on in there.
So it's not easy to find where the fault is located.

If we split the functionality inside the method using helper methods we can better test and understand where things gone bad.

Note here our enrollStudent method: if something fails in there can be a fault in setting the school functionallity , setName or Both. This method has no isoletabillity!

class Student{
    private name: string = "";

     setName(name:string):string{
         this.name = name;
         // 20 lines of functionallity
         return this.name;
     }




     enrollStudent(name:string,schoolID:number){
         this.setName(name);
        // set the school functionallity
        // lots of things here
        // like 30 lines of code
     }
}

Refactoring our code now our method is using helper methods to achieve the same functionality but now we can better test the method and it's helpers to be able to effectively trace the fault.

class Student{
    private name: string = "";

     setName(name:string):string{
         this.name = name;
         // 20 lines of functionallity
         return this.name;
     }


     setSchool(id:number){
         // lots of things here
         // 30 lines of code
     }


     enrollStudent(name:string,schoolID:number) {
         this.setName(name);
         this.setSchool(schoolID);
     }
}

Automatabillity

The goal is to be able to automate testing our functionality, to strive for code that can be tested and verified programmatically.

Assume we are developing a weather application , instead of relying on the actual api and having delays , network errors and other things out of our control, we can build our own mock api to simulate the functionality and to be able to better automate the testing process.

Recap

Writing our code to be testable makes it well organized, modular and loosely coupled.

This naturally leads to software that is clean and easier to maintain.

This article has been published on linkedin

Photo by Pixabay from Pexels

Typescript Tips and Tricks

Achilles Moraites — Wed, 29 Jan 2020 08:50:46 +0000

Here are two Typescript tricks to make your life as a software developer easier.

Make an interface that has any number of attributes of a specific type

Ever wondering if you can find a middle ground between the any type and of a specific type/interface ?

The answer is yes!
You can make an interface that contains any number of attributes of a specific type while having the ability to have any attribute name:

interface Person {
  name: string;
  age: number;
}

interface FlexInterface {
  [index: string]: Person;
}

// now you can use it like
const Group: FlexInterface = {
  alice: {
    name: 'Alice Byers',
    age: 24
  },
  brian: {
    name: 'Brian Sanders',
    age: 16
  }
};

// still this will fail!

const Group2: FlexInterface = {
  alice: {
    name: 'Alice Byers',
    age: 24
  },
  brian: {
    name: 'Brian Sanders',
    age: 16
  },
 // Type 'string' is not assignable to type 'Person'
  matt: 'Mathew'
};

Taking advantage of this technique you can create flexible types without using type any !

Create a type that has a partial match of another type

This effectively means that we can match any number of properties of a given type:


interface Person {
  name: string;
  age: number;
}

type PartialPerson = Partial<Person>;

function updatePerson(personToUpdate: Person, attributes: PartialPerson) {
  return { ... personToUpdate, ...attributes };
}

let person: Person = {
  name: 'John Doe',
  age: 8
};


// this works as expected
const attrs1: PartialPerson = {
  age: 38
};

// this will fail
const attrs2: PartialPerson = {
  hobbies: ['chess', 'swimming', 'coding']
};

person = updatePerson(person, attrs1);

I you have some tips and tricks of your own feel free to share them in the comments below!

Happy coding :)

Credits

Photo by Yogendra Singh from Pexels

Simplify your Angular Component testing

Achilles Moraites — Fri, 17 Jan 2020 12:01:53 +0000

Components are everywhere in our apps and testing them is part of our daily software development process.

But here are some good news: Testing should not be hard!

There are 3 types of tests for our Components:

Isolated (fastest)
Shallow (fast)
Deep (not so fast)

In this tutorial we will explore Isolated tests

Isolated Tests

Those are the less utilized tests in Angular testing yet the most fast and simple to use.

In those kinds of tests we treat the Component as a simple class.
Testing classes is easy, we can call their methods and verify the results.

Note that we just test the class functionality and NOT anything in the DOM.

Case 1 (simple) the component has no dependencies

Here is our component:

// explorer.component.ts

import { Component, OnInit } from '@angular/core';

@Component({
  selector: 'app-explorer',
  templateUrl: './explorer.component.html',
  styleUrls: ['./explorer.component.scss']
})
export class ExplorerComponent implements OnInit {

  explorerName: string;
  location: string;
  constructor() { }

  ngOnInit() {
  }

  getLocation(location) {
    this.location = `Your location is ${location}`;
  }

}

Here we perform tests:

// explorer.component.spec.ts

import { async, ComponentFixture, TestBed } from '@angular/core/testing';

import { ExplorerComponent } from './explorer.component';



describe('Isolated ExplorerComponent Tests', () => {
  let component: ExplorerComponent;
  beforeEach(() => {
    component = new  ExplorerComponent();
 });

  it('should set the correct location', () => {
   component.getLocation('Mars');
   expect(component.location).toContain('Mars');
 });

});

We can test it just like any other class!

Case 2 : the component has dependencies

here is our service:

// explorer.service.ts

import { Injectable } from '@angular/core';
import { of } from 'rxjs';

@Injectable({
  providedIn: 'root'
})
export class ExplorerService {

  constructor() { }

  getExplorer() {
    return of('Josh the Lost');
  }

  getLocation() {
    return 'The dark side of the moon';
  }
}

our component:

// explorer.component.ts

import { Component, OnInit } from '@angular/core';
import { ExplorerService } from './services/explorer.service';

@Component({
  selector: 'app-explorer',
  templateUrl: './explorer.component.html',
  styleUrls: ['./explorer.component.scss']
})
export class ExplorerComponent implements OnInit {

  explorerName: string;
  location: string;
  constructor(
    private explorerService: ExplorerService
  ) { }

  ngOnInit() {
    this.explorerService.getExplorer().subscribe(data => {
      this.explorerName = data;
    });
  }

  getLocation(location) {
    this.location = `Your location is ${location}`;
  }

}

our tests:

// explorer.component.spec.ts

import { async, ComponentFixture, TestBed } from '@angular/core/testing';

import { ExplorerComponent } from './explorer.component';
import { of } from 'rxjs';



describe('Isolated ExplorerComponent Tests', () => {
  let component: ExplorerComponent;
  // create a spyObject to simplify our mock service creation
  const mockExplorerService = jasmine.createSpyObj(['getExplorer']);
  // set the getExplorer method to return an Observable just like the real one
  mockExplorerService.getExplorer.and.returnValue(of('Dave the brave'));

  beforeEach(() => {
    component = new  ExplorerComponent(mockExplorerService);
 });

  it('should set the correct location', () => {
   component.getLocation('Mars');
   expect(component.location).toContain('Mars');
 });

  it('should set the correct explorer', () => {
  // trigger
  component.ngOnInit();

  expect(component.explorerName).toEqual('Dave the brave');
  // verify that getExplorer from the service has been called
  expect(mockExplorerService.getExplorer).toHaveBeenCalled();
});

});

Conclusion

Using Isolated tests we can test functionality with a simple way that is performant and easy to understand.

Note that this approach is great for testing just the component (class) code and is not meant to replace TestBed in any way.
We can just combine different kinds of tests to compliment our testing efforts :)

Happy testing !!!

Photo by Rodolfo Clix from Pexels

A developers guide to Run Puppeteer on Elastic Beanstalk (no ubuntu linux)

Achilles Moraites — Fri, 03 Jan 2020 07:41:55 +0000

The problem with running puppeteer on elastic beanstalk is that chrome is not included by default.

This has been published on Medium

Make sure you have

Installed EB CLI you can find it here
Configured the EB CLI make sure you setup ssh for your instances !

Install chrome on elastic beanstalk

Connect with ssh to elastic beanstalk
To connect with ssh the easiest way is to use:

eb ssh

after you have connected, run the following command

curl https://intoli.com/install-google-chrome.sh | bash

the command above fetches and runs the installation script on elastic beanstalk.

Lets Use it

After we have chrome installed we need to setup puppeteer to use it instead of the default chromium that will not work no matter what.

here you can see a simple snippet of how we can use puppeteer to take a screenshot of a page in www.example.com , note the executablePath is pointing to the directory where our installed chrome lives.

'use strict';                                               
const puppeteer = require('puppeteer');

(async() => {

const browser = await puppeteer.launch({executablePath: '/usr/bin/google-chrome-stable',
headless: true, args: ['--no-sandbox', '--disable-setuid-sandbox']});

const page = await browser.newPage();

await page.goto('https://www.example.com');                                                               

await page.screenshot({ path: 'screenshot.png', fullPage: true });

browser.close();

})();

Congrats you can now use Puppeteer on elastic beanstalk !

cover photo by Magda Ethels

Design Patterns — Composite

Achilles Moraites — Thu, 19 Dec 2019 08:19:01 +0000

This has been posted on Medium

The composite design pattern is about a hierarchy where nodes with children have different behavior than childless nodes.

The pattern consists of three elements:

Component : a super-class typically an interface
Composite : a node with children implements Component
Leaf : a childless node implements Component

A typical example is a file system where there are folders and files:

Folders can contain files , other folders or can be empty. On the other hand files don’t contain folders or other files!

Remember , the most important aspect of a design pattern is it’s intent! Once you understand it, you can use the pattern effectively in your projects!

Project : FileSystem

get the source code here

Here you will explore a simple file system , where you can see a simple implementation of the pattern.

Here you can see a UML of our File System :

Take a moment to explore the code and:

note what component of the pattern each class represents
observe the output of the code and see the difference between a file and a folder
in what scenarios do you think this pattern would be useful?

Project : Extending our FileSystem

get the source code here

Time to get your hands dirty:

Now that you understand how the composite pattern works , lets extend our FileSystem by adding new file types!

Take the code and implement a new File type: Img

General Guidelines:

The Img should implement FileComponent
Img must have a data field, you can use anything you like
You can use the display method of the file to customize it for the new file
Create an Img object and add it to a folder!

By the end of this project you have applied the pattern in an existing code-base and gained practical experience applying it.

See the solution

Happy coding !!!

Lazy loading modules in Angular

Achilles Moraites — Fri, 13 Dec 2019 13:12:56 +0000

This has been posted on medium

As we develop our applications you might have noticed that the initial load speed gets slower as the application is being developed, especially on mobile devices and slow networks.

Imagine that you are developing an e-commerce web app that allows people to buy and sell products.

So you have pages for:

Searching products and people
Store page
Product page
User profile
Login/Registration

As a good developer you had organized the code in modules, but as the application grows the problem is only getting worse …

But first lets find out why.

What is happening?

Any modules you have used above are loaded on the application start even when they are not needed, this translates to:

Slow initial page load/speed: The perceived performance of the application is LOW.
That happens because the users have to wait for the browser to download all the modules, even those that are not needed at the given time!
Excessive network data usage: Mobile internet in many countries is expensive and slow. That means that visiting your application costs MONEY and TIME for each user!
Poor mobile performance: If you combine the above you have an application that is not mobile friendly.
Does not matter if you do RWD (Responsive Web Design) as the excessive volume that has to be downloaded and run on the application start is a sure way to make it unresponsive for a couple of seconds.
This becomes even worse on low end mobile devices…

Summarizing: loading almost everything on the application start is a terrible idea.

Why to lazy-load modules

To avoid all the bad things mentioned above we will need to lazy-load any module that has no need to be loaded on application start.
If the user of your application on the app start is on the search page there is no need to load any module that is no being used in the search page, as the user might never need to use them:

For example what happens if a user just searches for a product and goes to the product page?

The user will just need the modules for the search and product display, all the other modules have no need to be loaded at all.
How to lazy-load a module

Assuming we want to lazy-load the UserProfileModule

The module:

@NgModule({
    imports: [CommonModule,                        
         RouterModule.forChild([                   
         {path: '', component: UserProfileComponent}    
     ])],
    declarations: [UserProfileComponent]
})

export class UserProfileModule{}

The example above is a simple module with a single component that we will lazy-load.

Inside our app-routing.module.ts

const routes: Routes = [{  path: '', component: SearchComponent  },
  { path: 'products/:productId', component: ProductDetailComponent},
  { path: 'profile',   loadChildren:'./userprofile.module#UserProfileModule'}
];

 @NgModule({
   imports: [RouterModule.forRoot(routes)],
   exports: [RouterModule]
})
export class AppRoutingModule { }

Notice that we use loadChildren instead of component and we provide the path to the module and we add to it at the end a hash # followed with the module class name: in our example we append #UserProfileModule
How it works

The UserProfileModule is moved to a separate file when we build the application.
When the user navigates to the profile the UserProfileModule is being lazy-loaded: The module is downloaded and then used by the application.

If the user never visits the profile this module will never be loaded!
That’s it you have just lazy-loaded a module in Angular!
Summary

Module lazy-loading gives you more control on what modules will be loaded, allowing you to reduce the app bundle and the initial load times.

Module lazy-loading gives you awesome superpowers!

Forem: Achilles Moraites

Github actions tweaks

Caching your packages

How

Create strings based on env variables

How

Use a custom npm config

How

Summary 👨🏻‍💻

Optimizing moment-timezone using webpack

But first, some facts

So we need the following timezone data

Optimizing based on our needs

Install the plugin

Adding the plugin to webpack

Design Patterns - Basic Iterator

How it works

Project : CarPartsStore

Types of Modules in Angular

Feature Modules

Core Module

Shared Module

Advanced Angular Testing using Jasmine

Show me the code

Now lets test the goBack() method

Testing browser specific APIs

Summary

Component Inheritance

About

Why

How

A simple example

Base component

ThemedInput component

Changing/Updating shared functionality

Testing shared code

Summary

Testable Code 101

What

Why?

How

Controllability:

Observabillity:

Isoletabillity:

Automatabillity

Recap

Typescript Tips and Tricks

Make an interface that has any number of attributes of a specific type

Create a type that has a partial match of another type

Credits

Simplify your Angular Component testing

Isolated Tests

Case 1 (simple) the component has no dependencies

Case 2 : the component has dependencies

Conclusion

A developers guide to Run Puppeteer on Elastic Beanstalk (no ubuntu linux)

Make sure you have

Install chrome on elastic beanstalk

Lets Use it

Design Patterns — Composite

Project : FileSystem

Project : Extending our FileSystem

Lazy loading modules in Angular

But first lets find out why.

Why to lazy-load modules

Now lets test the `goBack()` method