DEV Community: Flamur Mavraj

Rrogat në IT (Programim)

Flamur Mavraj — Sun, 01 Aug 2021 07:17:20 +0000

Po flasim pak për rroga! Një temë goxha e nxeht, por dhe shumë aktuale në një treg të eger të IT’s, më saktesisht në programim.

Keto definime (sic i kam cekur më posht) bazohen pjeserisht në praktikat e kompanis që udheheq dhe janë pik reference.

Mbi gjitha unë besoj që cdo kompani duhet të këtë një politik të drejt dhe që çdo puntor duhet të marr një rroge që e meriton dhe të ndihet i shperblyer për punën që bënë.

Gjithashtu një kompani, përpos rroges, duhet të punoj me punëtoret dhe të jap hapsirë që punëtoret të ngriten/zhvillohen dhe në menyr profesionale.

Personalisht, kur diskutoj për rrogë me dikend, gjithmonë bazohem në keto pika:

Njohurit aktuale të fushes/pozites
Mentaliteti dhe kultura e punës
Potenciali

Kurse titulli dhe shkollimi për mua asnjëher nuk kan qen si kerkese/kriter. Me duhet të cek që studentet nga FIEK dhe UBT veçohen në fushen tonë. 🙌

Junior Developer 📖

Një person që vetem sa ka filluar karrieren e tij, si zakonisht ka përfunduar shkollen formale (ose i vet mesuar) dhe ka përfunduar punen praktike.

Rroga fillestare për nje Junior, të sapo punësuar, duhet të filloj nga 400 deri ne 750 EUR. Kurse periudha kohore sillet mes 0-3 vjet punë të rregullt.

Intermediate Developer 🔨

Një developer që me disa orientime/udhezime të vogla kryn pune të medha. Përndryshe developerat e tillë mund të quhen edhe klasa punetore e një kompanie.

Rroga fillestare për një developer mesatar fillon nga 700 deri ne 1100 EUR, dhe periudha kohore është 2 - 5 vjet punë të rregullt.

Senior Developer 🚀

Developerat e mirë kushtojn, një developer i mirë, senior, është dikush që ka njohuri të mira programimi dhe aftesi për ti kanalizuar ato tek pjesa tjeter e ekipit. Rroga fillestare per nje Senior Developer është 1100+ EUR, kurse periudha kohore sillet mbi 4 vite prevoj pune të rregullt.

Për fund …

Ndoshta nuk je i pajtimit me kete qe thash, dhe është në rregull. Më shumë deshirë pranoj mendimin tënd në këtë aspekt në qoft se deshiron ta ndash me mua dhe të tjeret ketu?!

Me duhet të potencoj dhe një her që keto standarde (definime) jan pika referuese sepse çdo person është unik dhe rroga definohet duke u bazuar në aftesite dhe virtytet që ka ai/ajo.

Në fund të dites, është tregu që e definon rrogen (supply vs demand)!

IE adds double XMLNS on SVG markup when converting to string

Flamur Mavraj — Mon, 10 May 2021 02:29:47 +0000

We where tasked/needed to serialize SVG files on a project we are working on, and while the first implementation worked well on most (normal) browsers, it did not take too long time before we got some complains that our images where not being displayed properly.

After some debugging we found out that all these cases where related to users using IE. And after dusting of my Windows laptop and started testing we could reproduce the issue ❤️ (as developer I get a relief when I can reproduce an bug)

After a quick search on Google for IE svg adding double xmlns following two links helped understanding the issue and led to a fix:

First implementation (Does NOT work on IE)

We do use Figma to design and create our SVG's, when exporting, the SVG contains the xmlns-tag by default.

Here is an SVG example showing a red circle where the xmlns-tag is already set:

<svg height="100" width="100" xmlns="http://www.w3.org/2000/svg">
  <circle cx="50" cy="50" r="40" stroke="black" stroke-width="1" fill="red" />
</svg>

The serialize function we used is straight forward using XMLSerializer:

export const svgSerialize = (el: SVGSVGElement) => new XMLSerializer().serializeToString(el);

This will result in following result:

<svg height="100" width="100" xmlns="http://www.w3.org/2000/svg"><circle cx="50" cy="50" r="40" stroke="black" stroke-width="1" fill="red"/></svg>

And as said this worked perfectly on all other browsers expect Internet Explorer. Here is the result of same image on IE:

<svg xmlns="http://www.w3.org/2000/svg" height="100" width="100" xmlns="http://www.w3.org/2000/svg"><circle cx="50" cy="50" r="40" stroke="black" stroke-width="1" fill="red"/></svg>

Yes you spotted right, yet another xmlns="http://www.w3.org/2000/svg"-tag has been added to the SVG :(

Browsers are strict on XML parsing and therefor the above image will not be displayed!

After some trial and errors here is how we fixed the issue.

The solution

First we removed xmlns tag from our SVG:

<svg height="100" width="100">
  <circle cx="50" cy="50" r="40" stroke="black" stroke-width="1" fill="red" />
</svg>

And our new svgImageToString function looks like this:

export const svgImageToString = (el: SVGSVGElement) => {
    // Serialize the SVG object, this will add an xmlns on IE
    const serialized = new XMLSerializer().serializeToString(el);

    // We then do convert back the SVG serialized string to new SVG 
    const parser = new DOMParser();
    const newSvg = parser.parseFromString(serialized, "image/svg+xml");
    const newSvgEl = newSvg.firstChild as SVGSVGElement;

    // We check if the new SVG has xmlns if not we added to it
    if(!newSvgEl.hasAttribute('xmlns')){
        newSvgEl.setAttribute('xmlns', 'http://www.w3.org/2000/svg')
    }

    // We serialize the new element again and return the result
    return new XMLSerializer().serializeToString(newSvgEl)
}

You are probably thinking why converting the SVG serialized string back to SVG object using DOMParser, due to our complex SVG's we where not able to detect and remove the double xmlns-tag in another way (yes we tried with regex).

Hope this will help others that will face this issue 😊

Comment if you have other alternatives to the solution!

Cheers :)

Node.js (Express) with TypeScript, Eslint, Jest, Prettier and Husky - Part 3

Flamur Mavraj — Thu, 27 Aug 2020 07:12:56 +0000

Let's start testing!

Why you should do testing?

Before we continue with our setup I wanted to say some words regarding why you should do testing.

Yes testing is time consuming, and from time to time also hard but testing will save your ass in the long run.

Different testing techniques/tools exists and you should not (dont need to) cover all of them, also if use use multiple techniques/tools try to find a balance to not repeat your tests.

Finding the balance on what to test and what not may be hard, specially if you work with large teams, so my suggestion is to set up some rules that everyone follows, here are some rules we at Ornio AS try to embrace when it comes to testing Node.js applications:

All utility and service functions should be followed with a test, this should cover most of our functionality since we use Repository (service) pattern.
Validations (we use Joi) should also be tested.
Test Error handling.
Test Middlewares using Supertest.
Test critical Controllers using Supertest.

❓ What about you? What do you test in your Node.js applications?

Jest

Jest is a delightful JavaScript Testing Framework with a focus on simplicity.

Installing Jest is easy, run the command below and you will install Jest including its type definition and Typescript Jest runner:

npm i -D jest @types/jest ts-jest

Then we need to do some configuration, by initiating Jest to generate its config file, run:

jest --init

Answer the questions as needed, here is our answers:

Choose the test environment that will be used for testing
Node

Do you want Jest to add coverage reports?
No

Which provider should be used to instrument code for coverage?
Babel

Automatically clear mock calls and instances between every test?
Yes

This will generate a file called: jest.config.js:

module.exports = {
    clearMocks: true,
    moduleFileExtensions: ['js', 'jsx', 'ts', 'tsx'],
    roots: [
        "<rootDir>/src"
    ],
    testEnvironment: "node",
    transform: {
        '^.+\\.tsx?$': 'ts-jest'
    },
};

We added some additional configuration in order to get jest and ts-jest running in our environment.

transform is setup to look for .ts and .tsx files and use ts-jest to run it.
moduleFileExtensions has also been updated with ts and tsx.

Alternative: Using preset to run ts-jest

Instead of configuring transform and moduleFileExtensions you can define a preset in your jest.config.js file.

ts-jest comes with 3 presets for you to use:

ts-jest/presets/default or ts-jest: Its the default preset. TypeScript files will be handled by ts-jest, leaving JavaScript files as-is.
ts-jest/presets/js-with-ts: Both TypeScript and JavaScript files will be handled by ts-jest.
ts-jest/presets/js-with-babel: TypeScript files will be handled by ts-jest and JS files will be handled by Babel

jest.config.js will look like this when using default preset:

module.exports = {
    clearMocks: true,
    roots: ['<rootDir>/src'],
    testEnvironment: 'node',
    preset: 'ts-jest'
};

Then go ahead and add a test script in your package.json file:

"scripts": {
    //...
    "test": "jest"
},

Since we don't have any logic in our app, we are going to create a utility function just for this purpose in order to to write a test for it, let's create something that checks if a parameter is and number. Create a file utils/isNumber.ts:

export const isNumber = (n: any) => {
    return !isNaN(parseFloat(n)) && isFinite(n);
}

Now lets write a test for it, We prefer to add tests on the same place as our code, utils/isNumber.test.ts:

import {isNumber} from "./isNumber";

describe('isNumber Utils', () => {
    it('Its a number', () => {
        [0, 1, 2, -1, 1.345e17, '1'].map((n) => {
            expect(isNumber(n)).toEqual(true);
        });
    });

    it('Its not a number', () => {
        [false, true, NaN, [], {}, '1a'].map((n) => {
            expect(isNumber(n)).toEqual(false);
        });
    });
});

describe is used to group tests and it defines a test. You can run multiple tests under it but try to keep each test as small as possible for better readability. On the other hand expect is a Jest function that is used to check a value and its used "always" with a matcher function, in our case toEqual

The test above will test different inputs towards our function and fail/pass based on its return.

When testing the golden rule is:

Cover all thinkable scenarios (not always possible) and create a test for it!

Jest is quite powerful so take a look into its documentation and explore it further more.

If you have any questions please do ask!

Supertest

With a fluent API, Supertest will help us test Node.js HTTP servers. Supertest is build upon Super-Agent Node.js library.

To install Supertest run:

npm i -D supertest @types/supertest

In order to test our app, we are going to do some refactoring, create an file under src/app.ts:

import express, { Application } from 'express';
import {routes} from "./routes";

// Boot express
export const app: Application = express();

// Application routing
routes(app);

Also we need/prefer to moved our routes definition into src/routes.ts:

import { Application, Router } from 'express';
import { PingController } from "./controllers/PingController";
import { IndexController } from "./controllers/IndexController";

const _routes: [string, Router][] = [
    ['/', IndexController],
    ['/ping', PingController],
];

export const routes = (app: Application) => {
    _routes.forEach((route) => {
        const [url, controller] = route;
        app.use(url, controller);
    });
};

This way we can start organize our application easier. Go ahead and create following controllers, first, src/controllers/IndexController.ts:

import { NextFunction, Request, Response, Router } from 'express';
export const IndexController: Router = Router();

IndexController.get('/', async (req: Request, res: Response, next: NextFunction) => {
    try {
        res.status(200).send({ data: 'Hello from Ornio AS!' });
    } catch (e) {
        next(e);
    }
});

And then src/controllers/PingController.ts:

import { NextFunction, Request, Response, Router } from 'express';
export const PingController: Router = Router();

PingController.get('/', async (req: Request, res: Response, next: NextFunction) => {
    try {
        res.status(200).send({ data: 'Pong!' });
    } catch (e) {
        next(e);
    }
});

And finally our src/index.ts file is refactored to this:

import {app} from "./app";

const port = 5000;

// Start server
app.listen(port, () => console.log(`Server is listening on port ${port}!`));

Now we can go ahead and create a test for testing our PingController using Supertest. src/controller/PingController.test.ts:

import request from 'supertest';
import { app } from '../app';

describe('Test PingController', () => {
  it('Request /ping should return Pong!', async () => {
    const result = await request(app).get('/ping').send();

    expect(result.status).toBe(200);
    expect(result.body.data).toBe('Pong!');
  });
});

We start with a normal Jest test by describing it and then we call request(app) chained using ´get('/ping')´ which is the route and then finally we use send() to send the request.

When the request is sent and result is populated with the data we then checked if the status is 200 and the body.data is equal to Pong!.

Supertest is quite powerful and can be used to send advance requests by modifying headers, generating/storing tokens etc. It supports all CRUD operations.

I strongly recommend you to take a look on their documentation for more information and what Supertest can do.

Thats all for now. Until next time happy coding :)

Source code

You can find the source code here.

Need help?

Comment here or ping me on Twitter and I will gladly try to help you :)

Whats next?

Docerizing an Node.js/Typescript (this) application (Part 4)

Node.js (Express) with TypeScript, Eslint, Jest, Prettier and Husky - Part 2

Flamur Mavraj — Sat, 08 Aug 2020 09:53:35 +0000

On this part we are going to configure ESLint, Pettier and Husky.

Head over to Medium to read the blog post:
https://medium.com/@oxodesign/node-js-express-with-typescript-eslint-jest-prettier-and-husky-part-2-f129188ce404

Add Google Analytics through GTM (Google Tag Manager) on Next.js

Flamur Mavraj — Tue, 28 Jul 2020 08:01:34 +0000

Last week we released a brand new website (https://uwork.no) for our amazing client (uWork AS) and had to get Google Tag Manager (GTM) up and running, easy, we thought! Well, not quite!

For those interested, the stack is:

Next.js
TailwindCSS
Laravel (API)
Kubernetes (K8S) hosted on DigitalOcean
Bitbucket with Bitbucket Pipelines for deployment

The problem

Since we had GTM already setup, we thought all we needed to do is to inject the GTM script. And so we did!

We checked if the script was loaded ✅, we also checked if GTM was loaded correctly using Google Tag Manager extension for Chrome ✅, yep everything looked OKEY!

Then after completed the checklist before release we pushed to PROD and run DEPLOY 🚀😎

Next day we where monitoring Google Analytics and found out that all the data where from the index page (path: /), so we started to investigate and found out:

Moving from page to page did not fire our GA tag!

The solution

After using the whole day researching and reading on internet and found different suggestions on how to solve this, below we will show you our implementation using the classic Google Analytics tag.

Inject GMT script in pages/_document.tsx:

<>
    {/* Google Tag Manager */}
    <script
        dangerouslySetInnerHTML={{
            __html: `(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
                new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
                j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
                'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
                })(window,document,'script','dataLayer','${GTM_ID}');`,
        }}
    />
    {/* End Google Tag Manager */}
    {/* Google Tag Manager (noscript) */}
    <noscript
        dangerouslySetInnerHTML={{
            __html: `<iframe src="https://www.googletagmanager.com/ns.html?id=${GTM_ID}" height="0" width="0" style="display:none;visibility:hidden"></iframe>`,
        }}
    />
    {/* End Google Tag Manager (noscript) */}
</>

Remember to replace / define GTM_ID!

Then create an page view util function, utils/gtm.ts:

export const GTMPageView = (url: string) => {
    interface PageEventProps {
        event: string;
        page: string;
    }

    const pageEvent: PageEventProps = {
        event: 'pageview',
        page: url,
    };
    //@ts-ignore
    window && window.dataLayer && window.dataLayer.push(pageEvent);
    return pageEvent;
};

After that we need to run "pageview" event on every page, this can be done by setting up an listener (routeChangeComplete) on our Router using useEffect, pages/_app.tsx:

import { AppProps } from 'next/app';
import Router from 'next/router';
import React, {useEffect } from 'react';
import { GTMPageView } from '../utils/gtm';

function MyApp({ Component, pageProps }: AppProps) {
    // ...

    // Initiate GTM
    useEffect(() => {
        const handleRouteChange = (url: string) => GTMPageView(url);
        Router.events.on('routeChangeComplete', handleRouteChange);
        return () => {
            Router.events.off('routeChangeComplete', handleRouteChange);
        };
    }, []);

    // ...
}

export default MyApp;

Almost done, now we need to add a new Custom Event to fire our GA tag.

In GTM console:

Go to Triggers and click "New"
Name it as desired, in our case I'm naming it "PageViewCustom"
Under "Trigger configuration" select "Custom event", and under "Event name" write "pageview" <- this should the same as defined in your code/function GTMPageView.
Then go to Tags find you GA tag and configure to use the event we just created above.
Test the changes and publish it :)

UPDATE: Another alternative

You can as well use "History Change" trigger to achieve the same result.

That's all! Happy tracking 🙃

Node.js (Express) with TypeScript, Eslint, Jest, Prettier and Husky - Part 1

Flamur Mavraj — Sun, 31 May 2020 21:55:45 +0000

I feel ❤ that everyone (waiting for reactions 😎) is using Typescript nowadays. So I thought I wanted to share with you how we setup our Node.js applications here at Ornio AS.

In this part we will be covering:

Project initialization
Setup Typescript
Setup Express.js
Setup Nodemon

Are you in the hurry, scroll down to the source code :)

Btw did I tell you this is my first post here @dev.to so share some love 👊.

Initialize the project

Create package.json by opening your terminal, create a folder (name it as you wish) and type:

npm init

Answer the questions prompt by terminal and confirm creation of the package.json file at the end.

Here is my package.json file:

{
  "name": "nodejs-express-typescript-howto",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "repository": {
    "type": "git",
    "url": "git+https://github.com/ornio-no/post-nodejs-express-typescript-howto.git"
  },
  "keywords": [
    "Nodejs",
    "typescript",
    "express"
  ],
  "author": "Flamur Mavraj (Ornio AS)",
  "license": "ISC",
  "bugs": {
    "url": "https://github.com/ornio-no/post-nodejs-express-typescript-howto/issues"
  },
  "homepage": "https://github.com/ornio-no/post-nodejs-express-typescript-howto#readme"
}

Install and configure Typescript

npm i -D typescript ts-node

typescript will install Typescript package.
ts-node will install Typescript node runner so we don't need to build the application everytime we do a change, will be used with Nodemon.

After the installation run following command:

npx typescript --init

This will create tsconfig.json file with default options enabled and comments describing each options.

So here is my file after some clean up:

{
    "compilerOptions": {
        "target": "es5",
        "module": "commonjs",
        "sourceMap": true,
        "outDir": "./build",
        "rootDir": "./src",
        /* Strict Type-Checking Options */
        "strict": true,
        "noImplicitAny": true,
        /* Module Resolution Options */
        "moduleResolution": "node",
        "baseUrl": "./src",
        "esModuleInterop": true,
        /* Advanced Options */
        "skipLibCheck": true,
        "forceConsistentCasingInFileNames": true
    },
    "lib": ["es2015"],
    "include": ["src/**/*"],
    "exclude": ["node_modules"]
}

I'm not going to describe each of the options above but following two options are important:

outDir Its the directory where we want to compile our source code to, others may call it dist as well.
rootDir Its the directory where our Typescript files are going to be located.

Next step is to setup scripts in package.json:

{
    // ...
    "scripts": {
        "start": "nodemon",
        "build": "tsc",
        "test": "echo \"Error: no test specified\" && exit 1"
    },
    // ...
}

start will start nodemon, will configure that later, at the end.
build will compile our code using Typescript based on our tsconfig.json-file.

Setup Express and start the server

Install needed packages:

npm i -S express
npm i -D @types/express

Since Express does not have build in Typescript definitions we need the second package.

Then create src/index.ts with following content:

import express, { Application, Request, Response, NextFunction } from 'express';

// Boot express
const app: Application = express();
const port = 5000;

// Application routing
app.use('/', (req: Request, res: Response, next: NextFunction ) => {
    res.status(200).send({data: 'Hello from Ornio AS'});
});

// Start server
app.listen(port, () => console.log(`Server is listening on port ${port}!`));

Let's stop for a minute so I can explain what's happening in the code above.

On our first line we import express and its definitions (remember @types/express). After that we initiate express and defines the port (to be used at the end). And before starting the server we add a simple route and its function with argument definitions.

So why do we need these definitions?
This is the power of Typescript, these definitions are signature of the functions/arguments and will tell us how to use them. Yes you can create your own definitions but I'm not going to explain that here. These definitions will help you writing better code!

Compile/build and run the application

To run your application first we need to build it and then run it.

npm run build

Then run it using node:

node build/index.js

In your console you should see: Server is listening on port 5000!.

You can test the server by using curl:

curl localhost:5000

It should return {"data":"Hello from Ornio AS"}.

Almost done, let's wrap it up with setting nodemon.

Setup Nodemon for development

While developing the application we need a better way of handling file changes without building and restarting the server each time, for this we are going to use nodemon.

Installing nodemon:

npm i -D nodemon

And then configure it by creating a new file named nodemon.json:

{
    "watch": ["src"],
    "ext": ".ts",
    "ignore": [],
    "exec": "ts-node ./src/index.ts"
}

This will let nodemon watch src folder, by watching .ts files and execute/re-run ts-node ./src/index.ts when these files change.

Lets run the server and go ahead change something in ./src/index.ts and you will see nodemon will detect the changes and restart the server:

npm run start

Where did start command come from? While configuring Typescript :)

Source code

You can find the source code here.

Need help?

Comment here or ping me on Twitter and I will gladly try to help you :)

Whats next?

Setup Eslint, Prettier and Husky (Part 2)
Testing using Jest and Supertest (Part 3)