DEV Community: Abdoulaye Traoré

Things I learned when I started as a dev

Abdoulaye Traoré — Tue, 27 Aug 2019 00:00:00 +0000

Disclaimer

Highly subjective post from the perspective of a junior developer just starting out in the field.

Context

To get into the subject matter, I have to talk a bit about my journey. I started out as a developer 3 years ago; at the time I knew nothing about the JavaScript world that I would later enter. I was a full-time intern while doing my computer science degree. It’s a system called apprenticeship in France, I won’t go into details in this post but you’ll find info here.

In my company, I integrated one of the product development teams under the tutelage of two people. The first one resigned six months in, and I stayed under the second person’s tutelage for the rest of the apprenticeship. He went on to become my mentor and to this day he’s my “Shifu” (teacher, but in Chinese) and friend.

All proceeded relatively well, I hit the 'this' bump hard(JavaScript devs will understand), composition vs inheritance meant something to me, I got lost in Vim (I eventually got out) and learned to use git (kinda, git is still magic to me). One of the highlights is that I got a Pikachu in place of a rubber duck for "duck duck" debugging, I guess you could say it was "pika pika" debugging. [insert pika pika meme]

I fell in love with JavaScript and the rest is history.

All good things have an end

“Shifu” resigned right before I signed on in the company for my first full-time job. “It's a familiar scenario”, they said, “It's a normal part of the cycle”, more experienced colleagues told me, “you'll get used to it eventually since you're just starting out” was one phrase that came out too. Well, spoiler alert, I haven't gotten used to it.

It was a blow, I expected it because we'd talked about it but still it didn't feel good. I felt uncomfortable for a long while after but I convinced myself that it was the impostor syndrome; that I was getting cold feet because I had to figure stuff out without a guiding light or a safety net to catch me if I fell.

Fast forward two years, another colleague resigns. We got along well and more importantly, I learned a lot from him. The uncomfortable feeling rears its head again but this time I knew that it wasn't cold feet. "Why is it bugging me so much?" I asked myself. I got along really well with him, ok, but surely it couldn't be only that since we still kept in touch? Ensue a period of introspection and I finally found an answer: I felt down about losing people who I considered mentors. Realization came late but I eventually understood the underlying truth.

I learned many things from these people and I could ask questions without dreading being ridiculed. We exchanged on a level playing field when it was just a random dev subject. I felt SAFE to ask, question, debate and consequently learn and grow. I could bounce off ideas on them and I was sure that a not-so-bright idea would be identified as such and there would be an explanation for that. People might say "well that's what a normal, more experienced developer should do", that is true but the reality is it's HUGE to a beginner. Confidence is a fickle thing to some, including me, and I cannot stress enough how important it is to know that the person you are interacting with, concerning work that you don't have a mastery of (whether that's even possible is a subject in and of itself), is willing to listen without looking down on you.

Ok, sure, we get it, they were awesome blablablabla, but hey wake up and smell the roses; people have lives, things change, that's the way it is and you can't do anything about it. I get that, I sincerely wished, and still do, the best for them in their career. What I want to talk about is not why or how they left, but the impact their mentorship had and continues to have on me as well as what they taught me.

What I was taught and what I learned

People, in my opinion, inherently want to grow, show that growth and finally be proud of what they have accomplished. The mentorship I received helped me do that. I was given the tools and allowed the freedom to use them on a day to day basis. It didn’t happen all at once. That’s the first thing I want to stress, PATIENCE. I was taught to forgive myself and realized that you don’t just become a programming god, it takes time and that is NORMAL. I repeat, NORMAL, for those juniors devs out there, let that sink in. You shouldn’t try to go faster than the music and it can be very detrimental to your confidence.

While we’re on that subject, CONFIDENCE, that fickle thing, is a double-edged sword. I would be on a high from achieving what I wanted on a task and go straight down because I spent two days on a bug. We as humans are, sometimes (experiences may differ), really good at finding the things that hurt us and ignore the things that can help us smile. Realizing that every error, every misspelled variable, every fuck up is an opportunity for growth has perhaps been my biggest gain. Be confident that you are growing, amass that experience and be sure that one day you’ll move on to bigger and harder problems but that forgotten comma or spelling error will still come back and bite you, only you’ll be better equipped to deal with it.

Organization is important. Note down what you’re doing, what you’re struggling with and anything that seems important. Human memory is not infallible and you can’t remember everything at all times. You’ll be able to refer back to your notes for accurate, in context information when needed. It’s also useful for something else: when you feel like you haven’t done anything, look back at all you wrote and be sure that you’ve put the work in.

Stress is real !!!! Take care of your mental health. Breaks are good, take them as much as you can depending on your work context. “Feeling guilty for taking a break ain’t it chief !”, jokes aside taking a step back actually helps you take further steps forward. When you feel frustrated and can’t seem to get anywhere, breathe, take a stroll, go get coffee or tea and chill for a minute.

Speak up, voice your opinion because others can’t read your mind most of the time. They can help you feel comfortable to talk but don’t shy away if it’s possible (social anxiety is a bitch). Speaking up doesn't work for everyone, there are other solutions out there and you should find the one that fits personally. The key is to communicate with those around you, about what you understand and more importantly about what you do not understand.

Don’t let anybody tell you “soft” skills are not important. First of all, they are not soft and second of all, they are as important, in my opinion, as “hard” skills.

Co-workers don't have to be your friends to have a positive effect on you, anyone whose mindset includes sharing knowledge and elevating others can have that effect. Find those among your colleagues that can help you reach new heights, it’ll be worth the trouble.

“You don’t know what you have until it’s gone” would be an exaggeration but I have to admit that it’s very difficult to measure what effect someone’s absence can have, so profit as much as you can if you have good mentors around you because it doesn’t always last (some say it never does but I dare to believe).

Impact

How has this affected me going forward? Well, several things come to mind.

I’m now mindful of associating people I look up to with a company. What do I mean by that? Well, it’s undeniable that my mentor had a good impact on me but it would be a fallacy to automatically think “this company is great for me”. It may be the case or it may not be, but it surely depends on more factors than just my relationship with one person because you’ll struggle when that person changes jobs.

I think the WHY is more important than the HOW now. Maybe it’s because I’ve been through so much code where I wish I could just ask the previous developer “what was your reasoning for this? What made you take this route rather than another one?”. It may also be because every time I would want to do something that I presented to my mentor, it was always be met with the question “why?”; if you don’t know why, chances are you don’t really know what you’re doing and it’s not going to end well.

Conclusion

What more is there to say? Great people, in my opinion, elevate the ones around them and help them better themselves. I’ve been lucky enough to work with good people who have helped me along and I am thoroughly convinced, now more than ever, that no one can do it alone.

I would like to mentor one day, to pay it forward and help another junior out there. That would be fun, and stressful but, ultimately, it’s worth a try.

Do you relate to this? What about your experience? Hit me up on Twitter or in the comments and take care.

A big thanks to Steven, Sam, Jean-Baptiste for advice and editing.

Photo by Nesa by Makers.

Migrating AngularJS tests From Karma to Jest

Abdoulaye Traoré — Fri, 27 Apr 2018 15:58:24 +0000

Disclaimer

This is just a write up of how we migrated our AngularJS tests to Jest, it's not a guide and there certainly are elements that I won't cover but I hope it helps somebody out there.

In this post it is assumed that you have some good knowledge in javascript unit testing configuration using karma, that you have heard or know of Jest and that NPM, Babel, Typescript are familiar to you.

This article explains what Jest and some other tools are pretty well.

Context

At the end of 2017, we started migrating our whole front-end code base to Typescript and Webpack. In my opinion, Typescript is a godsend for large enterprise javascript code bases and we appreciate it. The old setup was getting complicated to maintain as it was custom made and didn't really follow javascript best practices.

Our front-end code is divided into two parts:

a library of reusable components that we use internally across all applications
the code that uses the lib and contains the application specific elements (views, custom components, services etc....)

The old setup required us to build the lib and then build the app that depended on it and a whole bunch of stuff that would give you nightmares; we even had "black magic" written in some places. If you ever come across such things in a code base, it doesn't smell good. I reckon even you agree we had to change stuff and change we did.

To get back on topic, after having setup our new build with Webpack and converted our js files to typescript; there was one last thing to do: make the tests work again !

Ah, didn't I tell you that ? Well in addition to what was previously mentioned, our tests weren't running anymore as a side effect of all the custom stuff.

The test setup was based on Karma/Mocha/Grunt/PhantomJS and just didn't work anymore. My first reflex was to update the tests to make them work with karma but that proved a more daunting task than I anticipated it to be. The plugin system
of karma can be cool but this time it was being more of a hassle than anything. I tried karma-typescript (really nice lib and awesome maintainer, shout out to @monounity); at first it went well, a majority of the library tests worked and all that but when I tried to run the application tests all hell broke loose. We used namespaces for the lib and karma-typescript didn't really like it so I opened an issue that monouty fixed but I then ran into other problems.

In light of all these issues, I couldn't make it work on time and had to leave it alone for a while, there were other things that needed my attention unfortunately. Fast forward to April 12th 2018, I was attending a meetup with a friend that was about TDD and BDD (an article about the meetup in french but with slides in english link) and they used Jest (woohoo, he's finally talking about it). I had heard of the framework and read this good article on using it for angular apps. This reminded me of my unfinished business with karma. I pitched Jest to my team and given my previous run-ins with karma, we decided to go ahead and migrate (don't know till you try) all our tests to it.

Migration

karma config

Here are the karma config files we used. The first one is for the app and there wasn't any attempt to make it work. The second one is for our internal library and is the one that I tried to make work.

Jest configuration

I started reading the official documentation (who said devs don't read the manual?) and there was a section about testing web frameworks that led to my previously mentioned article and this lifesaving piece by @benbrandt. There aren't many articles about Jest + Angular out there and trust me you need it when doing this kind of migration.

Typescript

We are using Typescript and Jest doesn't natively support it so we need a preprocessor to do the job. Enter TS-Jest, it does it all for you.

So we end up with a transform that looks like this.

    "transform": {
      "^.+\\.ts?$": "ts-jest",
    },

I also had to create a separate tsconfig file for ts-jest because it doesn't support all the options that we use in our typescript config file. I also disabled the TsDiagnostics but you shouldn't

    "globals": {
      "ts-jest": {
        "tsConfigFile": "test-tsconfig.json",
        "enableTsDiagnostics": false
      }
    }

Namespace

I read the articles for a bit, and started creating the configuration file for the library tests. The first problem I ran into was managing our namespace. After reading the docs for a while, I saw the moduleNameMapper option and that was it, problem solved.

    "moduleNameMapper": {
      "customNamespace/(.*)$": "<rootDir>/src/$1",
    },

Loading html files

We use webpack for our build and load html files using webpack's html-loader. I needed the same functionality for the tests. A couple of google searches later I found this stackoverflow issue. After reading all the comments and answers, I decided to follow their advice and create a custom preprocessor for Jest (yes Jest allows you to do that).

All that's left is to include it in the config.

    "transform": {
      "^.+\\.ts?$": "ts-jest",
      "^.+\\.html$": "<rootDir>/src-test/utils/htmlLoader.ts"
    },

Making sure img tag doesn't break my tests

In some of our html templates, we directly import images and that doesn't work with Jest; you need to stub it. Searching on the internet brought me to this package jest-static-stubs that is just perfect for the job. In the moduleNameMapper section of the config we just add the right line:

    "moduleNameMapper": {
      "customNameSpace/(.*)$": "<rootDir>/src/$1",
      "^.+\\.(jpg|jpeg|gif|png|mp4|mkv|avi|webm|swf|wav|mid)$": "jest-static-stubs/$1"
    }

Angular-mocks and global jquery

Due to how certain things work with angular ( this is better explained in mr brandt's article) we have to expose certain values (Jquery, Angular) on the global scope. In addition to that we need to import angular-mocks so that Angular sets up the app prior to running the tests. This is all in the form of an init file that is later referenced in the Jest configuration.

Init file content:

Referencing config in Jest config:

"setupTestFrameworkScriptFile": "<rootDir>/src-test/utils/init.ts",

Library config

We ended up with a configuration for Jest like this in our package.json:

That was it for our library tests and we even had code coverage without adding anything else. The cherry on top for me as a vs-code fanboy is the existence of this extension. The extension is pretty cool and I would recommend checking it out if you use vs-code and Jest.

Moving on to the application tests, I thought it would be a straightforward copy-paste and adapt thing.... Little did I know other issues were awaiting.

ES6 module support

As previously stated, our code is split into two parts: a library that is an npm module and the applications that depend on it. The library is written in typescript and we compile to es6. I needed to configure Jest to correctly load es6 modules and this issue had the answer somewhere in the thread. The solution was to use babel-jest for js files (my node_modules in this case) and to add a .babelrc file to my project containing:

The transform part of Jest config became :

    "transform": {
      "^.+\\.js?$": "babel-jest",
      "^.+\\.ts?$": "ts-jest",
      "^.+\\.html$": "<rootDir>/src-test/utils/htmlLoader.ts"
    },

The final Jest config is not that different from the lib one :

Comparison with Karma

The performance between Jest and Karma cannot be compared as there is no reference from the time the karma tests worked. I can tell you that Jest takes 38.425 seconds to run 92 tests organised in 9 test suites and run coverage. We went from 13 to 4 dependencies (jest, ts-jest, babel-jest, jest-static-stubs) needed to run our tests. PhantomJS is not needed anymore since Jest uses JSdom; that can be seen as an advantage or a disadvantage since we are no longer testing against real browsers. I hope testing against real browsers can be an option for Jest in the futur.

Conclusion

It wasn't easy but in my opinion it was worth it; we now have a more maintainable and modern test configuration. Testing can be fun with the right tools and I hope that we can add to our test base on a more regular basis with this setup.

A big thanks to the open source community without which this wouldn't have been half as easy. Hope this helps you.

A big thanks to Steven, Sam, Jean-Baptiste for advice and editing.

Photo credit goes to @weilstyle.