Forem: Bornfight

Check yo' project structure before you wreck yo' project structure

Davor Tvorić — Mon, 04 Apr 2022 09:48:50 +0000

I gotta admit, when it came to structuring a frontend project, I didn't really know why people considered it that important. I've mostly been working on smaller projects either alone or with 2-3 people. The projects' structure didn't matter all that much because they were abandoned as soon as we were finished with the project. With this kind of experience you might get lulled into the feeling that the default setup is all that you need.
I realized there's a lot more than meets the eye when I started working on an existing project that was a couple of years old. Just imagine being plopped in a foreign structure where you have to think about every little detail and question yourself constantly!
I started thinking a lot more about where I'd place a function, partial or a simple object. By just spending some time thinking about what would be the most logical solution, I've (hopefully) improved mine and everyone else's developer experience.

The catch is that I still have a lot to learn. I'm sure there's some things I haven't even considered because they're manageable at the time. But I don't see that as a bad thing, since that's something that could probably be improved. That's why I think it's important that you review how you structure your projects once in a while.

In this article, I'll explain why we've had the idea for a standard project structure within our team. My experience is related to frontend, but you might find something interesting even if you work in something else! But if you're in need of an actual structure, I'll be showing that in some other post.

How can you condense complex project structures into a single template?

Our projects' structure can vary a lot depending on the length of the project, the complexity, the features, and a number of other factors. However, I think we can make a generic structure which would work great in most cases. Now you're probably thinking, what about existing projects? It might be really complex (and inefficient) to change the whole structure in an existing project, but who says that you have to change absolutely everything? If you're going to work on a project for some time, why not make it easier for yourself if it's possible? After all, you've probably gathered a lot of knowledge throughout the years and could surely improve on the parts you designed at the beginning of the project.

Tackling this problem might not even be as complicated as you might think. Just writing down and explaining each folder/file will give you insight about your current situation.
From there you can easily see whether the decisions you made make sense! When I did this, it really felt like a game of Sudoku. When it seems like there's nothing else that can be done, you stumble upon a couple of smaller things here and there and, suddenly, a huge playing field opens up. That's my method for handling larger and older projects that are in time for a tune up.

Many projects, even more factors, but not enough resources

I work in an agency, but we work on projects of varying lengths. Some are done in a month's time and some are worked on for years. We're not limited to one technology, so that's also another factor. That's just a couple of things, but our structures can be wildly different. This means that each time you switch projects you have to get used to a different structure, as well. By not having a defined standard within the team, it meant that new projects would succumb to the same fate. That's more cognitive load that you don't want to have.
To counter that, we've researched which structure would fit us the best. Most of our focus was on scalability, readability, and extendibility. That's a lot of -bilitys, but in simpler terms we wanted to make sure that the project structure we made is easy to understand, use and improve. Sounds really simple, but to find something concrete on the Internet proved to be somewhat of a tough task. We were defining this structure for our frontend projects where the technologies are relatively young. Therefore, there's a lot of resources that show their ideas on really small examples with little experience in larger projects. It also doesn't help that only some use actual architectural patterns that are commonly used in software development.
We did manage to find some resources that really helped us out:

Contemporary Front-end Architectures by Harshal Patil
Infinum Frontend Handbook
How to structure frontend application by Michal Zalecki
Folders-by-feature structure
Container component

There's a lot to learn from each resource, but we didn't use every single thing from them. Each part was discussed and made sure that it really worked for us. It helped that we could decide as a team because each of us had some experience in something the others didn't, so it's important not to dismiss anyone's opinion.
After defining a structure, there's two last steps that were incredibly important and made everything click:

Explain each segment so that someone with less experience can understand it with relative ease
Just by using your explanation from the last step, create a smaller app to test out your structure

These steps were vital to adding most of the finishing touches. If we hadn't done them, we would have shot our own leg when we started a new project. It makes sense testing out what you did, but it is tempting to skip this part since you've already done the majority of the work. It will also help you to objectively look at the work you've done. Don't forget that everything can be improved!

Final words

Following this plan we came up with a concise CRA template (and Vue template) with a detailed README. Now we're able to preserve the same project structure throughout multiple projects and relieve ourselves of the cognitive load when switching to other projects.
This does not mean that our work is over, but it should be less of a hassle to have a great foundation and improve everything from here.

And if that doesn't sound great, I don't know what does!

Phone Number Normalisation

Ajdin Mustafić — Mon, 28 Mar 2022 13:16:42 +0000

The phone number normalisation is used to translate a phone number into a standard form.

For example, there is E.164 international standard which defines format as "[+] [country code] [subscriber number including area code] and can have a maximum of fifteen digits". However, we rarely save numbers, especially domestic ones, in this exact format.

This can be a huge problem if you wanted to allow your users to import their mobile phone contacts into your application. The users can have the phone number, in their phone contacts, entered with or without country code, or can enter country codes like 00385 or +385, etc. So if you didn't have the phone number normalisation, these two numbers 00385991234567 and +385991234567 would be imported as two different phone numbers for the same contact even though when calling, they are the same, just written in different format standards.

We have a similar challenge on one of our projects, so our first step was to research, what should be covered and what others cover when they do the phone number normalisation.

One of my outputs were the test cases that are covered by Whatsapp:

I can't contact a foreign mobile number without a country code - For example, if your phone number is from Croatia and you saved a contact with a mobile phone number from Austria, without the country code, Whatsapp will not recognize it as existing.
I can contact domestic mobile number without country code - For example, if your phone number is from Croatia and you saved a contact with a mobile phone number from Croatia, without the country code, Whatsapp will recognize it as it is (existing).
I can contact a foreign mobile number with "00" country code - For example, if your phone number is from Croatia and you saved a contact with a mobile phone number from Austria, with the 0043 country code standard, Whatsapp will recognize it as existing.
I can contact a foreign mobile number with a "+" country code - For example, if your phone number is from Croatia and you saved a contact with a mobile phone number from Austria, with the +43 country code standard, Whatsapp will recognize it.
I can contact a foreign mobile number with "+" country code and 0 before the mobile prefix - For example, save the foreign phone number in your contacts with "+" country code and zero before the mobile operator prefix (+385 0 99 1234567). Whatsapp will recognize and normalise the number to +385 99 1234567.
I can't contact a foreign mobile number with "00" country code and 0 before mobile prefix - For example, save the foreign phone number in your contacts with "00385" country code and zero before mobile prefix (+385 0 99 1234567). Whatsapp will not recognize the number as the same as +385991234567.
I can't contact domestic mobile number with "00" country code and 0 before mobile prefix - For example, save the domestic phone number in your contacts with "00385" country code and zero before mobile prefix (+385 0 99 1234567). Whatsapp will not recognize the number as the same as +385991234567.

Handling phone numbers, especially without normalisation can create a real mess in your application because many users in different countries use different phone number standards to create their contacts.

Feel free to share your experience and your test case examples in the comments section.

Starting as a Junior QA? Don't worry, I got you

Mario Tupek — Tue, 22 Mar 2022 10:13:37 +0000

Almost 5 years ago, I've started my QA journey as a student (AKA Junior) and didn't even know what QA was! Little by little, I started picking up pieces of what QA might actually be and how to do it properly. A lot of mistakes were done in the first year (tbh, it was the hardest one for me personally), but as the years went by, it gradually became easier because of all the knowledge I've managed to gather. This post will have a few tips for all my fellow Junior QAs' that are just starting out and hopefully, you can learn from my mistakes.

1. Write down everything

This is the most crucial part that will make your life much easier. When you are testing web app, mobile app, TV app, etc., you HAVE to write down every single thing you notice while testing. Reason for that is very simple: You'll forget to report it later. That's it. It happened to me and it happens to everyone. We're not robots that can remember every scenario that we've tested, step by step. We're only humans that have errors. Those things that you'll write down (whether it's on plain paper, notepad, code comments, etc.), they will become useful when an unexpected issue appears and someone asks you if it happened before. And guess what, you'll have a log of it written somewhere and explain that it was tested and eventually reported issue.

2. Devs are your best friends

You might think this is not possible, but when it happens, it's the best relationship within a project (or a whole company) you can have. At the beginning, devs will hate you, prepare for that mentally, because it can be exhausting to hear "It's a feature, not a bug" a million times. In those moments, if you are really certain that it's actually a bug, you can ask another dev for a second opinion. In some cases, it really can happen that it's a feature, no matter how hard you really see it as a bug, and that is perfectly fine. You've done your part and move on for more testing. Just remember that, in this relationship, you have your best intentions to break their code for better product at the end. :)

3. Don't forget your main goal

Usually as a junior, forgetting what's on your plate for testing is really easy. You want to prove yourself to the others by reporting as many bugs as possible, and it's completely natural to do that, but one thing to understand: You've been given a goal to accomplish under defined deadline and with certain requirements. Follow those requirements and you'll be golden. By reporting visual issues (icons and pixels misaligned, missing exclamation mark, colour is 5% brighter than in design, etc.) before incoming release, you'll create a mess inside your team and nobody needs to think that product is not working properly. Your time for reporting those issues will come. Sticking to your main goal is something you should have on your mind, day by day, as you're testing a product.

4. Testing only acceptance criteria is not enough

Everyone can test it, and you're not everyone. You are QA, and your job is to think outside of acceptance criteria (AC). Every issue that you'll discover will mainly be between the lines of written AC and it's your job to turn on your special QA skillset that you possess and break the AC, little by little. It's your time to get into the shoes of all those end users that will be using your tested product. Think of every possible way they can use it, convert it into cases and test it.

Summary

Hopefully these tips might come in handy to some of you, as they would certainly have helped me when I started as a junior. What do you think about them?
Let me know in the comments if you have any other tips or disagreements you'd like to share.

Traditional Education vs Self Taught Route in Programming (2022 edition)

Luka Kukina — Mon, 14 Mar 2022 14:23:30 +0000

This blog post will be written from the self taught programmer's perspective.
Backstory: after I graduated from college (Nutrition), I started learning programming in my free time: HTML, CSS, JavaScript and React. I was able to land my first job after just 3 months of studying, but ever since then, I was wondering if I should have went to a Computer Sciences university of some kind...

5 Years of College vs 3 Months of Self Taught

College gives you a plan, it gives you a structured path of learning, it gives you dedicated teachers who are teaching you stuff in a particular order, but...
College also gives you an extensive overview of everything that programming has to offer. I would probably have to learn plenty of technologies that I would not be interested in, many of the subjects that are not directly connected to programming would be hard to pass and if I went to college for 5 years, I would "lose" 20x more time to get a first "real" job...

The good thing about the self taught route is that you can turn your focus completely and solely on technologies that interest you and that you want to master.
On the other hand, there are a lot of questions that are hard to answer if you are on your own:

where to start from?
how to distinguish what is crucial to understand if you want to move forward?
what is not so important?
why are there so many ways to write things and who should I listen to?
is this still being used??

(so many questions 🤯).

And that brings us to...

Imposter Syndrome

I am not sure how it goes with the imposter syndrome when you have a computer science degree, but when you're a self taught programmer - it is very real. You will often think that things you don't know are actually some basics that you should have known. Also, you won't have the strongest programming foundations, and because of that you will think there must have been a better way to solve a problem. You won't feel as good reviewing a PR or giving advice, and you won't feel as competent as people with a computer science degree.
But, it's not always that bad, especially because the IT industry is full of very friendly people that are understanding and always willing to help you out.

Information Availability

It has never been easier or faster to get information you need. Because of that, more and more people are successful in becoming self taught programmers. But, that is not necessarily making it easier. With so much (different) information, paths and advices, it might be overwhelming for people and make them feel uncertain if they are moving in the right direction - it may even make them quit.

Job Opportunities

There are so many IT companies in the world and there are more of them each day. The amount of code that needs to be taken care of is huge and the amount of code that still needs to be written is even bigger. The point is: There are not enough developers in this world! This fact makes a computer science diploma less important when it comes to landing a job. Almost everybody should be able to land a job as a junior developer because there is such a large need for developers right now. You need to be a good fit for a company (sometimes more important than the actual knowledge), and you'll become a master of your craft as you work on a real world problems.

If I had to do it all over again

Many people might say that self taught programmers got it easy by bypassing college, but I actually think that it is the harder path. If I had to start all over again from high school, I would definitely go to a computer science college and earn myself a degree. But if I had to do it all over again from the point where I already graduated from Nutrition, I think I would choose a self taught route again, but this time I would also try to become a part-time computer science student to have a structured curriculum and a certainty that I have the necessary foundation.

Conclusion

Like with everything else, there are good and bad aspects on both paths. Many programmers that I've met said that everybody is a self taught to a certain extent. I agree with that, college would give me a wide spectrum of knowledge, but when it comes to mastering a craft, you have to dig deep on your own. By now, I was able to progress to a mid level JavaScript developer and at this point I think I have more benefits by working on real world projects, so I don't see myself going to college again. But, if you are in the similar position, I hope this post helped you in making your decision.

First 6 months: Dreams vs Reality

Valentin Vuk — Mon, 07 Mar 2022 09:17:44 +0000

So six months have passed, 350 commits have been made and 147 daily meetings attended...here is a short recap of what I have expected versus what that looked like in reality.

"Well, dreams, they feel real while we're in them right? Its only when we wake up that we realize that something was actually strange." - Cobb

The Code

Like every one of us, I have learned my craft mostly on online tutorials. And there you touch on really wide subjects. In my case, as a react developer, that would be react router, storybook, animation libraries, testing, internalization and concepts like spa, ssg and ssr to name a few. And here is me walking into my first job thinking I will use all those tools daily.

Well, that didn’t work as planned. In reality, the best way to describe how it actually is: you dive in and work much deeper, but with much less tools. And these tools depend on the project that you get assigned. Sometimes it sucks not working with the stuff that you find interesting and engaging, but that is the reality of having a job. On the bright side, there’s plenty of interesting things to learn in the depth of every tool.

"Musn't be afraid to dream a little bigger, darling." - Eames

Scrum is like your mother-in-law, it points out ALL your faults

I imagined my everyday working flow to look something like this: senior developer on the project gives me one detailed task for a week or two, and my communication is solely with him or in rare cases with the backend team - and that’s it.

Ken Schwaber had other ideas. Because of this guy, things called organization, communication, time and task management, planning etc. came into my life. Daily meetings, story points, estimations...whole new world. To this day it is a work in progress, and also - scrum development isn’t particularly student friendly. But as I wrote in the title of this section, it points out all your flaws and gives you something to work on - really important characteristics for your future successful career.

"Look if you want my help, you're gonna have to be completely open with me. I need to know my way around your thoughts better than your wife, better than your therapist, better than anyone." - Cobb

The Squad

Totally expected to work with Richards, Gilfoyles, Jian Yangs characters of the world, sometimes with a bit of Mark Zuckerberg ego on the side. Very hard to engage with, even harder to learn something from them.

I still remember my first few days where I was actually shocked how incredibly brilliant, but also so down to earth and approachable everyone were. From giving me advice, to playing Fifa on lunch breaks and having great time on our "spontaneous" parties. Impressed.

"I got someone better!" - Miles

The Conclusion

In retrospect, it's incredible how much you can be in the wrong with expectations (👋 estimations). Also, our developer community is incredible in real life too, even better, because you have that human touch too. And for my fellow students, I recommend you start exploring jobs, because you learn so so much - not only about the technical stuff, but more importantly, the processes of developing a product, organizational skills and the mindset behind successful programmers and companies.

5 Mistakes I’ve Made as a Junior Flutter Developer

Zvonimir Vujnović — Mon, 28 Feb 2022 20:03:12 +0000

So you want to learn Flutter. Maybe you’ve seen a cool job opening for Flutter developers or wanted to try how it compares to native development of Android or iOS apps. You’ve started learning Flutter and it seemed pretty cool, right? You wanted to learn more and more and the hunger for Flutter knowledge doesn’t stop? Well it might be a time to slow down and reflect on what you’ve learned. Maybe try to be a bit self critical. See what could’ve been done better. After all, Flutter is a new technology and many times there isn't a right or wrong answer. Here are some mistakes I made as a Junior Flutter Developer:

1. Ignoring native development

A few years before I started learning Flutter, I started developing Android apps using Kotlin. Unfortunately it didn't last long because I was a student and didn’t have enough free time to further increase my Android skills.
Today, I can see clearly that the basics of both Android and iOS would be a useful background. Maybe it isn’t the worst mistake not to learn native development but it sure does help. As you develop more and more Flutter projects, you’ll find yourself opening android and ios folders more often. Sometimes you may have to tweak native code to get desired behavior. (A good example would be implementing native splash screens - although nowadays, there is a package for everything.)
Overall, it is generally considered a good practice to have experience with native development before starting Flutter. Surely, it isn’t a must to get you going with Flutter but at some point you’ll need to understand the concepts of native development.

2. Not making everything a widget

One way of implementing a DRY principle in programming is always extracting a repeating logic into a function. This led me to extracting repeating UI components into functions but I’ve realized soon that this kind of approach is no good.

Flutter is a bit different in that way. Since we want our app to be as performant as it can be, we need to minimize the amount of rebuilds it’s making. For example, imagine having a screen with a button that is changing color on click. Performance wise, you’d only want to rebuild that button when the color has changed. If you use something like the code below, the whole screen will rebuild every time!

Scaffold(
  body: Column(
    children: [
      ...,
      ...,
      ...,
      ElevatedButton(
    style: ElevatedButton.styleFrom(primary: color),
        onPressed: () {
          setState(() {
            changeColor(),
          });
        },
        child: const Text(‘Button’),
      ),
    ],
  ),
);

The key is to extract that button in a separate widget and move the color changing logic into that new widget. As you call setState(), only that widget will be rebuilt and the rest won’t. Now, it probably doesn’t sound that important, but when you have some heavy-computing happening and/or the screen itself is rebuilding frequently (animations can be performance heavy), there is a possibility that the app will lag. To further understand this topic, I would recommend this video: https://www.youtube.com/watch?v=IOyq-eTRhvo. I myself started to use this approach only after seeing this video (yes I’m ashamed) because I never, to that day, had a reason to optimize my app.

3. Lack of state management

If you’ve read my previous mistake, you may wonder how you can change the color of our button widget from another widget that is higher in widget tree. What happens if some other component needs to change the color of the button? Well, the solution to that problem isn’t trivial.
That’s why we use state management solutions. Some of the most popular state management solutions are Provider, Riverpod, BLoC and GetX.
When I first started my Flutter journey, I only used setState() as my state management approach. As far as I think, it isn’t bad to start that way because then you know exactly what happens with your widgets and how Flutter is rebuilding and drawing your screens.
As soon as you start making more complex apps, everything will become a mess. You’ll have trouble finding anything in your code since it will probably be spaghetti code. The best way to clean that mess is to implement a state management solution. That way you’ll decouple UI components from the business logic and everything will have its place in your project.
I personally started with BLoC but didn’t find it that helpful nor simple. A few months ago I was introduced to Riverpod and never looked back. Anyway, it’s a matter of personal preference and you should find what works for you and stick with it.

4. Using too many packages

Flutter is a framework developed with simplicity in mind. If you aren’t new to Flutter, you’ve probably heard: There is a package for everything - and yes, there almost literally is. When developing a new feature chances that someone already implemented it and made a package for others to reuse it are pretty high. It's as simple as plug'n'play.
Of course, if you want to become a good Flutter developer and know what’s happening under the hood of those packages, you’ll probably want to implement it yourself. It might be time consuming but it is the best way to actually learn fundamentals.
When I first started learning Flutter, I was a victim of this mistake myself. I would start working on a new feature and the first thought that would cross my mind was: Let’s check if there is a package for that! Unfortunately, the package was there in 90% of situations. Just later, I realized that no package is without its flaws.
Imagine the situations where you need to develop a feature which already has a package dedicated for it but it just lacks that little thing that you need. You have no choice but to write it on your own. Having experience doing things yourself will definitely come in handy.

5. Not being consistent

Flutter provides you with package flutter_lints in every new project by default if you are using Flutter 2.3.0-12.0.pre or newer. It provides the latest set of recommended lints that encourage good coding practices.
When I first started, I wanted to learn as much as possible and go through the Flutter framework as quickly as I could. The result of that was inconsistent code with a lot of bad practices which were error prone. My life changed when I started using the lint package.

No more single quotes double quotes dilemma. Choose one and stick with it. (Personally I use single quotes in Flutter projects because imports are automatically added with single quotes.) Functions without return types don’t exist anymore. I started avoiding using var. And so on and so forth.
Personal favorite lints of mine are always_declare_return_types and always_specify_types.
Introduction of lints in my projects made my code cleaner, better and most important more consistent.
Like in every other project (or anything you do in life) consistency is key.

Conclusion

To conclude, don’t be discouraged if you are making some of these mistakes as well but always strive to learn more and do more. These were my top 5 mistakes and I hope you can learn from them, because I most certainly did. Feel free to share some of the mistakes you’ve made when starting with Flutter!

Animate a frame by using a transition between main image colors

Goran Hrženjak — Mon, 21 Feb 2022 11:34:49 +0000

A disclaimer right away - this is not really about animating image frames; it's just animating the background behind the image and adding some padding.

I wanted to draw more attention to some images in a grid of uploaded images in one of my projects. Instead of having a plain card design or having to tweak borders and shadows around those images, I came up with this technique.

The idea is to extract the main image colors and compose a gradient with transitions between them. This gradient will "circle around" the image making it look more lively and vibrant.
At the same time, each image will have its own unique animated gradient which, in my opinion, will make the transition between the image, image frame and container background color more seamless.

To achieve that, main image colors are extracted for each image. This "palette" of colors is used in composing the aforementioned gradient.

A couple of examples:

The code was mainly influenced by this script by Kepler Gelotte:
Image Color Extract

Input parameters are path to the image, number of colors to extract and delta - the amount of gap when quantizing color values (1-255). The smaller the delta, the more accurate the color, but also - number of similar colors increases.

<?php

declare(strict_types=1);

namespace App\Service;

class ColorPaletteExtractor
{
    private const PREVIEW_WIDTH = 250;
    private const PREVIEW_HEIGHT = 250;

    public function extractMainImgColors(string $imagePath, int $colorsCount, int $delta): array
    {
        $halfDelta = 0;
        if ($delta > 2) {
            $halfDelta = $delta / 2 - 1;
        }

        $size = getimagesize($imagePath);
        $scale = 1;
        if ($size[0] > 0) {
            $scale = min(self::PREVIEW_WIDTH / $size[0], self::PREVIEW_HEIGHT / $size[1]);
        }

        $width = (int) $size[0];
        $height = (int) $size[1];
        if ($scale < 1) {
            $width = (int) floor($scale * $size[0]);
            $height = (int) floor($scale * $size[1]);
        }

        $imageResized = imagecreatetruecolor($width, $height);

        $imageType = $size[2];

        $imageOriginal = null;
        if (IMG_JPEG === $imageType) {
            $imageOriginal = imagecreatefromjpeg($imagePath);
        }
        if (IMG_GIF === $imageType) {
            $imageOriginal = imagecreatefromgif($imagePath);
        }
        if (IMG_PNG === $imageType) {
            $imageOriginal = imagecreatefrompng($imagePath);
        }

        imagecopyresampled($imageResized, $imageOriginal, 0, 0, 0, 0, $width, $height, $size[0], $size[1]);

        $img = $imageResized;

        $imgWidth = imagesx($img);
        $imgHeight = imagesy($img);

        $totalPixelCount = 0;
        $hexArray = [];
        for ($y = 0; $y < $imgHeight; $y++) {
            for ($x = 0; $x < $imgWidth; $x++) {
                $totalPixelCount++;

                $index = imagecolorat($img, $x, $y);
                $colors = imagecolorsforindex($img, $index);

                if ($delta > 1) {
                    $colors['red'] = intval((($colors['red']) + $halfDelta) / $delta) * $delta;
                    $colors['green'] = intval((($colors['green']) + $halfDelta) / $delta) * $delta;
                    $colors['blue'] = intval((($colors['blue']) + $halfDelta) / $delta) * $delta;

                    if ($colors['red'] >= 256) {
                        $colors['red'] = 255;
                    }
                    if ($colors['green'] >= 256) {
                        $colors['green'] = 255;
                    }
                    if ($colors['blue'] >= 256) {
                        $colors['blue'] = 255;
                    }
                }

                $hex = substr('0' . dechex($colors['red']), -2)
                    . substr('0' . dechex($colors['green']), -2)
                    . substr('0' . dechex($colors['blue']), -2);

                if (!isset($hexArray[$hex])) {
                    $hexArray[$hex] = 0;
                }
                $hexArray[$hex]++;
            }
        }

        // Reduce gradient colors
        arsort($hexArray, SORT_NUMERIC);

        $gradients = [];
        foreach ($hexArray as $hex => $num) {
            if (!isset($gradients[$hex])) {
                $newHexValue = $this->findAdjacent((string) $hex, $gradients, $delta);
                $gradients[$hex] = $newHexValue;
            } else {
                $newHexValue = $gradients[$hex];
            }

            if ($hex != $newHexValue) {
                $hexArray[$hex] = 0;
                $hexArray[$newHexValue] += $num;
            }
        }

        // Reduce brightness variations
        arsort($hexArray, SORT_NUMERIC);

        $brightness = [];
        foreach ($hexArray as $hex => $num) {
            if (!isset($brightness[$hex])) {
                $newHexValue = $this->normalize((string) $hex, $brightness, $delta);
                $brightness[$hex] = $newHexValue;
            } else {
                $newHexValue = $brightness[$hex];
            }

            if ($hex != $newHexValue) {
                $hexArray[$hex] = 0;
                $hexArray[$newHexValue] += $num;
            }
        }

        arsort($hexArray, SORT_NUMERIC);

        // convert counts to percentages
        foreach ($hexArray as $key => $value) {
            $hexArray[$key] = (float) $value / $totalPixelCount;
        }

        if ($colorsCount > 0) {
            return array_slice($hexArray, 0, $colorsCount, true);
        } else {
            return $hexArray;
        }
    }

    private function normalize(string $hex, array $hexArray, int $delta): string
    {
        $lowest = 255;
        $highest = 0;
        $colors['red'] = hexdec(substr($hex, 0, 2));
        $colors['green'] = hexdec(substr($hex, 2, 2));
        $colors['blue'] = hexdec(substr($hex, 4, 2));

        if ($colors['red'] < $lowest) {
            $lowest = $colors['red'];
        }
        if ($colors['green'] < $lowest) {
            $lowest = $colors['green'];
        }
        if ($colors['blue'] < $lowest) {
            $lowest = $colors['blue'];
        }

        if ($colors['red'] > $highest) {
            $highest = $colors['red'];
        }
        if ($colors['green'] > $highest) {
            $highest = $colors['green'];
        }
        if ($colors['blue'] > $highest) {
            $highest = $colors['blue'];
        }

        // Do not normalize white, black, or shades of grey unless low delta
        if ($lowest == $highest) {
            if ($delta > 32) {
                return $hex;
            }

            if ($lowest == 0 || $highest >= (255 - $delta)) {
                return $hex;
            }
        }

        for (; $highest < 256; $lowest += $delta, $highest += $delta) {
            $newHexValue = substr('0' . dechex($colors['red'] - $lowest), -2)
                . substr('0' . dechex($colors['green'] - $lowest), -2)
                . substr('0' . dechex($colors['blue'] - $lowest), -2);

            if (isset($hexArray[$newHexValue])) {
                // same color, different brightness - use it instead
                return $newHexValue;
            }
        }

        return $hex;
    }

    private function findAdjacent(string $hex, array $gradients, int $delta)
    {
        $red = hexdec(substr($hex, 0, 2));
        $green = hexdec(substr($hex, 2, 2));
        $blue = hexdec(substr($hex, 4, 2));

        if ($red > $delta) {
            $newHexValue = substr('0' . dechex($red - $delta), -2)
                . substr('0' . dechex($green), -2)
                . substr('0' . dechex($blue), -2);

            if (isset($gradients[$newHexValue])) {
                return $gradients[$newHexValue];
            }
        }

        if ($green > $delta) {
            $newHexValue = substr('0' . dechex($red), -2)
                . substr('0' . dechex($green - $delta), -2)
                . substr('0' . dechex($blue), -2);

            if (isset($gradients[$newHexValue])) {
                return $gradients[$newHexValue];
            }
        }

        if ($blue > $delta) {
            $newHexValue = substr('0' . dechex($red), -2)
                . substr('0' . dechex($green), -2)
                . substr('0' . dechex($blue - $delta), -2);

            if (isset($gradients[$newHexValue])) {
                return $gradients[$newHexValue];
            }
        }

        if ($red < (255 - $delta)) {
            $newHexValue = substr('0' . dechex($red + $delta), -2)
                . substr('0' . dechex($green), -2)
                . substr('0' . dechex($blue), -2);

            if (isset($gradients[$newHexValue])) {
                return $gradients[$newHexValue];
            }
        }

        if ($green < (255 - $delta)) {
            $newHexValue = substr('0' . dechex($red), -2)
                . substr('0' . dechex($green + $delta), -2)
                . substr('0' . dechex($blue), -2);

            if (isset($gradients[$newHexValue])) {
                return $gradients[$newHexValue];
            }
        }

        if ($blue < (255 - $delta)) {
            $newHexValue = substr('0' . dechex($red), -2)
                . substr('0' . dechex($green), -2)
                . substr('0' . dechex($blue + $delta), -2);

            if (isset($gradients[$newHexValue])) {
                return $gradients[$newHexValue];
            }
        }

        return $hex;
    }
}

I was getting the best results when working with 6-10 colors and delta between 20 and 35.

CSS is pretty simple:

.gradient-background-animation {
  background-size: 400% 400% !important;
  animation: BackgroundGradient 10s ease infinite;
}
.card-picture-container {
  padding: 0.875rem; // This value determines how big the "frame" will be
}
.card-picture-container img {
  object-fit: contain;
  max-width: 100%;
}

@keyframes BackgroundGradient {
  0% {
    background-position: 0 50%;
  }
  50% {
    background-position: 100% 50%;
  }
  100% {
    background-position: 0 50%;
  }
}

You can adjust the layout and the rest of the styling per your liking.

HTML:

<div class="container">
  <div class="card-picture-container gradient-background-animation" 
       style="background-image: linear-gradient(-45deg, #78785a,#5a783c,#3c5a1e,#969678,#b4b4b4,#1e1e1e,#d2d2f0)">
    <picture>
      <img src="/images/source/image.jpeg" alt="">
    </picture>
  </div>
</div>

As you can notice, background is added as inline CSS.

Final result (size decreased for preview purposes):

I've created a Twig extension (filter) and included it in my Symfony project.

<?php

declare(strict_types=1);

namespace App\Twig;

use App\Service\ColorPaletteExtractor;
use Twig\Extension\AbstractExtension;
use Twig\TwigFilter;

class GradientExtractorExtension extends AbstractExtension
{
    public function __construct(
        private ColorPaletteExtractor $gradientExtractor,
    ) {
    }

    public function getFilters(): array
    {
        return [
            new TwigFilter('get_gradient', [$this, 'getGradient']),
        ];
    }

    public function getGradient(string $imagePath, int $colorsCount, int $delta): string
    {
        $colors = $this->gradientExtractor->extractMainImgColors($imagePath, $colorsCount, $delta);

        $filteredColors = array_filter($colors, fn (float $percentage) => $percentage > 0);

        return join(',', array_map(fn (string $color) => '#' . $color, array_keys($filteredColors)));
    }
}

image-grid.html.twig

<div class="container">
    {% for image in images %}
        <div class="card-picture-container gradient-background-animation"
             style="background-image: linear-gradient(-45deg, {{ asset(image)|get_gradient(7,30) }}); animation-duration: 8s;">
            <picture>
                <img src="{{ asset(image) }}" alt="">
            </picture>
        </div>
    {% endfor %}
</div>

Photos for testing purposes downloaded from https://www.parkovihrvatske.hr/parkovi

Awesome Shopify Resources for 2022

Mario Loncarek — Mon, 14 Feb 2022 09:04:18 +0000

Shopify released a lot of new features in 2021, and naturally new tools and resources needed to be developed to cover new features. Next is a list of awesome Shopify Resources for 2022 which will help you to create modern Shopify storefronts.

1. Dawn

Dawn is Shopify's own open source theme with performance, flexibility, and Online Store 2.0 features built-in and acts as a reference for building Shopify themes. Its great for using it as a starter theme for your new Shopify project.

2. Dawn Figma files

If you will use Dawn as a starter theme for a Shopify project, Shopify give us this great Figma file with all Dawn's components/sections/templates that you can send to designer to speed up the design process.

3. Shopify Markets

In my opinion Shopify Markets will be the biggest update to Shopify since releasing Online Store 2.0 but will be even bigger than that. Markets will finally allow us to create Market-specific buying experiences. That means native multiple currencies, languages, language specific domains, duties collection for each market etc. It's currently available as a preview feature so I suggest that you don't sleep on this one!

4. Hydrogen

Another great open source Shopify resource, but this time for creating headless experience. Hydrogen is React-based framework for building custom storefronts on Shopify which gives you everything you need to start fast, build fast, and deliver the best personalised shopping experiences.

5. Helium

Helium is a great resource for using newest Online Store 2.0 features with modern build tools. Helium will allow you to use ES6, SCSS and hot module reloading for both. Great to use in combination with Shopify's Dawn.

6. HULL

Hull is another resource for creating headless experiences, but Hull is a complete starter powered by Next.js + Sanity.io. It has a lot of features so you can use it as a complete solution for your headless project.

7. Shopify Theme Lab

Another complete headless solution, but this time for the Vue.js fans, and also you can swap Vue.js for pretty much anything if that stack is not suitable for project.

8. goCart.js

A complete open source Shopify Ajax cart solution written in vanilla JS. This plugin includes Ajax cart drawer, Ajax mini cart, add to cart modal, and error modal. Developed by Bornfight's frontend team and new, re-written version will be released this year.

Fastest Symfony authentication - AWS Cognito integration

Alen Pokos — Mon, 07 Feb 2022 09:35:26 +0000

If you either love AWS services already, or are looking for a good option to use with your multiplatform products, AWS Cognito seems to be a good candidate to adopt into your technical stack.

For me it was unknown, but once I started digging into it, I find it to solve some problems I was bored with solving.

Setup Cognito on AWS

For starters, we should prepare our Cognito user pool.
We can do this via AWS UI. On the Cognito page we select "Create new user pool".
There are no really special settings you need to configure upon creation,
so choose either default settings or settings that fit your needs.

Only thing we need from user pool is to setup APP client.
Configure the APP client as you need.
For the callback URL we will target symfony route /security/cognito/check ie: http://localhost:8000/security/cognito/check.
If using local Symfony, be careful about using http or https domains. Spent some time to figure that one out because I was reckless :D.

Symfony

At the time of writing this article, Symfony 6 was the newest version and used to test this code.

Symfony installation

To be able to follow this post, you should either have an existing Symfony project or create a new one.
For ease of example, I will provide quick intro how to set up a new clean Symfony project.

We start with the new symfony project symfony new --webapp .
Please, see Documentation on installation and setup of Symfony project.

To verify we installed successfully, we can run server using symfony server:start.

Install and configure packages for Cognito integration

Now that we have Symfony and Cognito ready, we can begin integration into our Symfony application.
We will use knpuniversity bundle that provides variety of built-in connectors, but it is missing Cognito one.
For that, we will install Cognito agent provided by another package.

composer require knpuniversity/oauth2-client-bundle cakedc/oauth2-cognito

Once installation is complete we begin to configure the bundle.
Update config/packages/knpu_oauth2_client.yaml:

knpu_oauth2_client:
    clients:
        # configure your clients as described here: https://github.com/knpuniversity/oauth2-client-bundle#configuration
        cognito: # name of our client
            type: 'generic' # type 
            provider_class: '\CakeDC\OAuth2\Client\Provider\Cognito' # class provided by agent package
            client_id: '<AWS_CLIENT_ID>' # Cognito app id
            client_secret: '<AWS_CLIENT_SECRET>' # Cognito app secret
            redirect_route: connect_cognito_check # name of the route where we wanna redirect callback, it mush be same as configued in the Cognito app
            provider_options:
                region: <AWS_REGION>
                cognitoDomain: <AWS_COGNITO_DOMAIN> # Cognito domain, just the domain, without region and aws suffix
                scope: 'email' #scopes configured in cognito

We also need some Symfony User. If you do not already have this, we can create it now.
If you already have user and user providers, you can skip this part and go to creation of connection controller.
Create user using maker bundle, bin/console make:user with settings:

store user in the database: NO # this is for demo purpose. In the real world you would probably wanna store it into a database
unique property: Email # this can be whatever you need
Hash/check password: NO # again, if you need it otherwise you can use it

This will generate:

src/Security/User.php Our User class
src/Security/UserProvider.php User provider class used by Symfony security. It will also update the security configuration config/packages/security.yaml with information about our new user provider.

If you are not familiar with these terms, I would urge you to read basics of Symfony security in Symfony Security documentation.

Next we need to create connection controller, that will provide routes and calls to oauth client bundle, ie:

<?php

namespace App\Controller;

use KnpU\OAuth2ClientBundle\Client\ClientRegistry;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\Routing\Annotation\Route;

class SecurityCognitoController extends AbstractController
{
    /**
     * Link to this controller to start the "connect" process
     */
    #[Route("/login", name:"connect_cognito_start")]
    public function connectAction(ClientRegistry $clientRegistry)
    {
        // will redirect to AWS Cognito!
        return $clientRegistry
            ->getClient('cognito') // key used in config/packages/knpu_oauth2_client.yaml
            ->redirect();
    }

    /**
     * After going to Cognito, you're redirected back here
     * because this is the "callback URL" you configured
     * in AWS Cognito APP settings
     */
    #[Route("/security/cognito/check", name:"connect_cognito_check")]
    public function connectCheckAction(Request $request, ClientRegistry $clientRegistry)
    {
        // ** if you want to *authenticate* the user, then
        // leave this method blank and create a Guard authenticator
    }

    #[Route("/logout", name:"security_logout")]
    public function logout(){}
}

Logout is currently not configured, and you can customize this to your needs later.

Last code class we need to create is custom Authenticator, by following KNP docs and guidelines:

<?php

namespace App\Security;

use CakeDC\OAuth2\Client\Provider\CognitoUser;
use KnpU\OAuth2ClientBundle\Client\ClientRegistry;
use KnpU\OAuth2ClientBundle\Security\Authenticator\OAuth2Authenticator;
use Symfony\Component\HttpFoundation\RedirectResponse;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\RouterInterface;
use Symfony\Component\Security\Core\Authentication\Token\TokenInterface;
use Symfony\Component\Security\Core\Exception\AuthenticationException;
use Symfony\Component\Security\Http\Authenticator\Passport\Badge\UserBadge;
use Symfony\Component\Security\Http\Authenticator\Passport\Passport;
use Symfony\Component\Security\Http\Authenticator\Passport\SelfValidatingPassport;

class CognitoAuthenticator extends OAuth2Authenticator
{
    private $clientRegistry;
    private $router;

    public function __construct(ClientRegistry $clientRegistry, RouterInterface $router)
    {
        $this->clientRegistry = $clientRegistry;
        $this->router = $router;
    }

    public function supports(Request $request): ?bool
    {
        // continue ONLY if the current ROUTE matches the check ROUTE
        return $request->attributes->get('_route') === 'connect_cognito_check';
    }

    public function authenticate(Request $request): Passport
    {
        $client = $this->clientRegistry->getClient('cognito');
        $accessToken = $this->fetchAccessToken($client);

        // NOTE: Here you can store token into session if you are using stateful authentication.

        return new SelfValidatingPassport(
            new UserBadge($accessToken->getToken(), function() use ($accessToken, $client) {
                /** @var CognitoUser $user */
                $cognitoUser = $client->fetchUserFromToken($accessToken);

                // NOTE: here you can load/save user from storage such as database

                $user = new User();
                $user->setEmail($cognitoUser->getEmail());
                return $user;
            })
        );
    }

    public function onAuthenticationSuccess(Request $request, TokenInterface $token, string $firewallName): ?Response
    {
        // change "app_homepage" to some route in your app
        $targetUrl = $this->router->generate('app_homepage');

        return new RedirectResponse($targetUrl);

        // or, on success, let the request continue to be handled by the controller
        //return null;
    }

    public function onAuthenticationFailure(Request $request, AuthenticationException $exception): ?Response
    {
        $message = strtr($exception->getMessageKey(), $exception->getMessageData());

        return new Response($message, Response::HTTP_FORBIDDEN);
    }
}

Please note the targetUrl in the onAuthenticationSuccess method. Customize this to your needs.
I will also provide simple controller at the end of the article for convenience of testing.

Last thing is to update our security.yaml configuration to use our custom provider:

...
firewalls:
    ...
    main:
        ...
        custom_authenticator: App\Security\CognitoAuthenticator

This is the main subsection, not the entire contents of the file. For our configuration, we only needed to add custom_authenticator setting that is our authenticator class.

Once done and you try it, by opening http://localhost:8000/login you should be redirected to AWS hosted login page.
After you login you will be redirected back to your symfony site with error exception from UserProvider::refreshUser.
If you just wish to try it out, you can return $user in this method.
Important!! This is for testing only, and it is not good practice. You should fit this to your implementation.

If you wish to see try it out, here is a simple test controller:

<?php

namespace App\Controller;

use Sensio\Bundle\FrameworkExtraBundle\Configuration\IsGranted;
use Symfony\Component\Routing\Annotation\Route;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Security\Core\Security;

final class DefaultController
{
    #[Route("/", name:"app_homepage")]
    #[IsGranted("ROLE_USER")]
    public function __invoke(Security $security): Response
    {
        // we return with html head and body tags as this is needed by Symfony profiler to attach to the page 
        return new Response(sprintf("<html><head></head><body>Welcome %s</body></html>", $security->getUser()->getUserIdentifier()));
    }
}

and you also need to update services.yml and add section load new controller:

    ...

    # controllers are imported separately to make sure services can be injected
    # as action arguments even if you don't extend any base controller class
    App\Controller\:
        resource: '../src/Controller/'
        tags: [ 'controller.service_arguments' ]

And there you have it. You can login into your Symfony application using AWS Cognito.

Feel free to clean up the code, improve the security of it and make it ready for the real world.

Security is important and sometimes hard topic. I would urge you to read Symfony Security documentation to better understand how it works, what are good practices and how to avoid pitfalls.

Have fun coding, creating and learning.

5 tips I wish I knew as a junior developer

Mario Loncarek — Mon, 31 Jan 2022 11:34:08 +0000

Here are some tips for junior developers or everyone who just started taking interest in becoming professional in the area, but especially for those who want to progress as quickly as possible. These tips come from my own personal experience and from mistakes I made which resulted in stagnation of my progress.

1. Kill the ego

This is the most important one. Stop thinking that you already know everything. Stop trying to get attention to show how much you know. Stop saying “I know that”. Relax - everybody knows that you are a junior, they know how much you know and they shape your tasks to fit that fact.

Coming into an agency environment for the first time in your life and thinking that you know something is a good sign of the level you are on. Know that every junior is a company’s investment for the future. It’s not expected that you make money for the company right away because you could not be independent in your work - when you’re a junior, there will always be someone checking after you, mentoring you and helping you when you get stuck. It's OK not to know everything and accept that, you are here to learn and that is what being a junior is.

Killing your ego is the first step in making progress. Thinking that you know everything is the biggest blocker you can do for yourself, and you will not progress or grow until you completely eliminate your ego. Stay humble, hustle hard.

2. Request a good mentorship

Now that you are ready to really learn and understand where you are, and on your path to becoming a better developer and worker, it’s time to understand how important it is to have a good mentor. I was very lucky to have the best possible person to mentor me, which made my skills skyrocket in a year or two. If you don't have one, request this from your company first thing in the morning. If a company would not provide you with a mentor, leave the company, that's not a good place for a junior developer, and it also shows red flags about how other aspects of the company are handled.

Good mentor is a life hack in becoming a really good developer and useful for your company in much less time than it would take you alone (we are talking years here). A mentor will give you all of the answers you need many times faster than Google or Stack Overflow will. Take every advice you can from a mentor, squeeze as much information as you can and absorb like a sponge. Realize what mindset you need in order to be on your mentor’s level. It’s really important to learn how to listen - you are here to ask questions and not to be smart. Insist on constant code reviews, and insist on them to be very critical, and understand that critical code reviews are for your own good. Never take them personally.

Never forget to respect your mentor because he is putting a lot of time and effort into making you a good developer and that is a very hard job to do, because knowing how to be a good mentor is a science on its own.

3. Show initiative

If you want to stand out as a motivated worker, show initiative. That’s what separates people who are only doing their jobs from someone who wants to grow constantly. And that’s what being a good worker really is - a person who is highly motivated and shows initiative. That kind of person adds value to the company and pushes things to be done.

Give constructive suggestions. Take the hardest task that no one else wants. Take ownership of the things you are doing and take responsibility for how they are done. But try to be useful while doing it, don’t just do things for the sake of doing them to show off - meaning don’t be fake!

4. Be the hardest working individual

Work hard and stay hungry. Seek to be the best developer in your company, but compete only with yourself. Not everyone has the same timeline, so never compare yourself to others. You are on your own path and things will come - and that will only depend on you.

Difference between being good and being great is proportional with the hard work you are willing to invest in your skill. Most of the time this will mean going an extra mile in your free time. Having a good life/work balance is important, but I do not regret working hard after my 9-5 job when I needed to understand things deeper because it helped me to get where I wanted to be and to learn much faster.

5. Understand how business really works

Don't think about the money at all as a junior developer. Only focus on learning, progressing and gathering real experience. You want to be on a level on which you are useful for the company and you can create real revenue with the work you do. Until that point you really don't have many arguments for some crazy salary. Money will come naturally, and a good company will never exploit your level, so don’t worry about being hungry, or recognize another red flag of a bad company.

But don’t fool yourself - realize early that when talking about the business side of everything, in the end it’s all about the money. Your salary depends on how much money you can earn for the company through your work. Companies can not do business if they are losing money. That's why employing a junior is an investment for the future of the company because companies lose money until you can be independent in your work and become useful. That also means that your salary will be bigger with more useful work you can do if you're into the money thing.

Of course, you can make more money on your own, but you will never become a great specialist if you don’t start working in the company first - that is where you will be given real experience, big projects and the best possible education. That’s all the things you will not get as a junior developer going on your own. And in my opinion, that will slow your progress - and we’re talking about years here.

Summary

These are the tips that would have helped me a lot throughout my junior years. What do you think about them?
Do you have any other tips or disagreements with any of them? Let me know in the comments.

Top 5 essential skills for fresh parents

TomislavNovacicBF — Mon, 24 Jan 2022 14:06:58 +0000

Intro

This article is all about work-life "balance" and how to continue progressing in your career after the baby comes. I will write about my conclusions and organisation in this new environment. We will wrap things up with 5 essential skills you can work on to prepare yourself for the arrival of the newcomer.

The comfort zone

Things are going great, you are learning new stuff and reading work-related articles on a daily basis. You are as motivated as ever, advancing really quickly and on your way to become a ninja developer (or other equivalent role). Your diet is on check and you are getting your workouts in. Nothing can stop you! And then one day you become a parent...

The chaos

At the beginning things are going good, but as the baby grows you start to realise that your free time becomes shorter and shorter, and soon enough you will have practically no free time. You now don’t have time for your partner or working out, let alone for personal development.

What to do now? How to continue working on your goals and be there for your child at the same time?

People always talk about work-life balance and you always thought it was some nonsense that lazy people say? Yeah, me too. Well there is some truth in that approach, because now you just have to make things work somehow. Save yourself a few months (or a year) of getting the hang on things and start working on this skills immediately if you are expecting kids any time soon.

Top 5 skills ambitious parent needs

1. Time management
Day only has 24 hours so try to get the best out of every minute.

Read whenever you have a few minutes to spare. Read while your partner is playing with the baby, when you're in the rest room, in the bed after everyone is asleep and you have few atoms of energy left.
Get up early. Wake up first and start your day in a complete peace (and use that time wisely).
Work from home. If you have the option to work from home, just take it - you’ll save a bunch of commute and getting-ready hours, and you can use that in a better way. If that is not a possibility for you, then travel to work with public transportation so you can do some work while you are on your way to the office. If you, for some reason, prefer the car over public transportation then you can listen to audio books or podcasts while driving.
Don't sacrifice sleep, it's counter productive after some time and it's not worth it in the end. Fresh mind = more focus = better productivity and more growth.

2. Organization

Try to plan every minute of your day up front. This enables you to see how much literature you can consume in a day. According to that you can set realistic goals and don't get frustrated thinking you've done too little that day. When you precisely estimate every action in your day, you unknowingly start to do repetitive tasks even more quickly (eating for example).

3. Multitasking

Incorporate learning in any activity that does not require your complete focus. Listen to audio books while you are grocery shopping, cleaning, cooking, in the gym or walking a dog.

4. Focus

Focus 110% while working. That is the only time of the day that is strictly dedicated for your work and personal growth. It’s also the only time when you’ll have complete peace and no distractions. You’ll start to appreciate those hours more.
Start adjusting to working in non-ideal environments. There will be times when you have to work or read and kids are screaming and running around, and you have to get used to it (it gets better over time I promise).

5. Dedication

Prioritise. Not all things you stumble upon on your go-to reading materials are important for your line of work. Read only about stuff that is applicable to your work and future aspirations, skip the rest.
Delete your social media accounts (or leave them but use them responsibly). The same goes for TV and gaming consoles. Time spent on these platforms is valuable and cannot be returned.

P.S. Don't forget to spend quality time with your family, don't be a stranger. This article focuses on the parts of the day you are "free".

Did I forget anything? Does any of this sound familiar to you? Feel free to react and comment down below.

iOS Code Review Checklist

ivcelic — Mon, 17 Jan 2022 16:11:36 +0000

To encourage iOS developers to approach code review more throughly we've built a simple check list that should be followed when going through an iOS pull request.

Of course we do not go through it and add checkmarks on every PR but we use it to remind us from time to time what should we look for when code reviewing. This is also a good start for someone who is new in iOS development or code reviewing in general.

1. Are there any merge conflicts in the PR?

If yes - return to assignee before looking further into code.

2. Did the static analysis check run?

eg. for checking the Swift code style we use Swift Lint

3. Check the architecture

eg. data should not be fetched or processed in presenters or in views
eg. views should not be modified in view models

4. Is the code consistent with the agreed coding guidelines?

5. Are there any new Xcode warnings introduced?

6. Prefer static constants over computed properties

Prefer

static let c: Int = 1234

Over

static var d: Int { return 1234 }

7. Check single source of truth principle

eg. don’t preserve the same information in multiple places in the code

8. Avoid singletons

use dependency injection instead

9.Look for force unwrapping

force unwrap should be avoided (use in < 1% of the cases)
Using ! should always be a red flag!
Check if early return from functions (eg. guard) is used

10.Constants

Extract constant to a struct

11.Check for magic numbers

Avoid harcoding, avoid magic numbers, if needed extract into a constant
If added, magic numbers should be commented

12.Check encapsulation

Check if public variable or function can be private or private(set)?
If a class won’t be ever instantiated - use enum instead.

13.Check polymorphism

Should we mark the class final?
Should we use class or static keyword for a function/variable.
Prefer composition with protocols over inheritance.

14.Check for single responsability

The function should have one purpose! Split it in two if makes sense.
The class should not have too many responsabilities - split if needed.
Avoid massive view controller, add managers, helpers, utils instead.

15.Check for explicit use of self keyword

Explicit (unneeded) use of self should be avoided because it makes the capturing semantics of self stand out more in closures, and prevents verbosity elsewhere

16.Performance check

use strings concatenation with /() instead of +
use isEmpty instead of == nil
use ! instead of == false
instantiate DateFormatter only once
reuse cells
use image caching
use background threads where needed
etc…

17.Error handling

Are all the errors cases handled in code? Log the error, notify the user, retry, fail safely…

18.Check security vulnerabilities

Are there any user passwords or other secrets stored as plain text?
Is there any sensitive data being logged?

19.Check naming

Is naming clear and consistent. The naming is important for writing self-documenting code!
Boolean values should start with is, can, should, will…
When in doubt - use longer names (adds more information) over shorter names (can bring confusion).
Use UpperCamelCase for types and protocols, lowerCamelCase for everything else.

20.Check duplicate code

Duplicate code is a big no no and should be extracted and reused!

21.Remove unnecessary code

Remove commented code. You can always get it back with git.
Remove empty and/or unused variables, functions, imports…
No need to add explicit init for structs if using only the default initialiser.

22.Memory leaks

Closures should use weak self
Delegates should be weak
Check if unowned is misused
Check for any retain cycles

23.Check if all strings are localised

24.Is the code covered with logs?

Every important event in the app should be logged.
The logs should contain enough information (class, function, parameters, severity).
Repeating information can pollute the log.

25.Is the code well documented?

Does every public function contain a comment?
Does the code contain a comment for every specific part of the code?
Does every specific class (manager, service, script…) contain a comment about their purpose?
Does every file contain a copyright?
Should the README be updated?

As mention before, we use this checklist as a reminder and a motivation for doing better code reviews. Thus, we are adding bullets to our checklist and improving it over time.

What would you add to the list? 🙂