Naguel

I'm Nahuel, and these are my work experiences, ideas and thoughts as a web developer working on the eCommerce industry.

Play spot the difference as part of your front end development process

Play spot the difference as part of your front end development process

I know that inside the front end development kingdom there are a lot of different sub species, different front end developers out there working in different stuff: a few more focused on the functionality closer to back end development, and some working on converting designs into code.

If you're a front end developer whose main task is to look at a PSD file and "make it happen" in code, then I can't stress hard enough how important is for the job that you achieve this successfully. And if you're thinking that this is obvious and there's no need for a post, trust me, it's still a common problem among developers... and it's hard to me to understand why.

What's the main task of a fire fighter? Extinguish a fire. What's the main task of a plane pilot? Fly the plane. Main task of a mother?... I have no idea, but my chips are on keeping the baby alive.

Jokes aside, what do you think is the main task of a a front end dev? Get a design, then implemented it as pixel perfect as it can be.

I saw this problem presented in a variety of seniorities, as it doesn't distinguish between Juniors and Seniors. Of course, the problematic is more present in lower seniorities, that's not surprise, but it still cause for rework in more experienced developers.

If "main task" seems like too much, as you probably thinking, just like I am, that a front end developers faces a lot of task during a day and it's hard to decide which one is the main one (again, related to the fact that your front end developer job description it's for sure different than the others), then just let's not get stuck in grammar.

It might not be your main task as a front end developer, but for sure is an obvious task, something that you should be already been achieving without anybody raising any doubt about it when you deliver.

So why aren't you? Or why you still have this problem in your team?

If it's your problem then awesome, today is a great day to start solving that. And if not your problem but something you see that happens within your team or company... then it's still your problem, sort of.

The most common excuses I heard about it is the lack of tools, or people using the wrong tools, to view and manipulate the designs.

"Oh, it looks different because I don't have Photoshop in my computer so I opened the document with other software that converts .psd files if you're using Linux."

That's not a good excuse and you know it.

We're missing a synchronization here between developers and people in higher position within the company when deciding on what tools to use. Are we going for Adobe Photoshop for the designs' team?, great, then let's make sure that we also have Adobe Photoshop in the developers' computers... and not Linux if we're going to deliver .psd files to them.

Here's another one, "We were on a hurry, so I couldn't spend time on making the implementation pixel perfect". I can only assume that the equivalent for that on a fire fighter would be something like "Oh, we were on a hurry, so we only extinguish the fire on the first floor".

That "explanation" is a symptom of a higher problem within the company that might deserves an individual post, but for the moment just stop the presses and evaluate if you're giving to the developer the necessary time to accomplish all the items included in yours definition of done. If not, then you're asking for the impossible.

On the other side, if you're the developer. Come on dev, stand your ground! Do not go for an impossible estimation knowing that you won't be able to deliver successfully. If the time frame won't allow you to go for a pixel perfect implementation, then speak up. If everybody is on board of what the outcome will be, then good, no surprises for nobody.

And finally, the Top 3 seems to be "I tested it on Chromium for Linux Mint and it looked exactly like the designs". Looks like a child of the first excuse, and still a bad one.

On the developer's side, ask for the specifics, ask what browsers you are supporting for that particular project, or ask for metrics from Google Analytics to know exactly what your final customers are using. And test, my friend, test it on more browsers (specially knowing that Chromium for Linux Mint can't have the final word).

If you're the company, or somebody with a technical seniority that have a say on technical decisions, then define what browser do you support and include them on your definition of done. Avoid having technical decision based on the personal believes of each developer on the team.

Spot the difference

Have you ever played that magazine or newspaper game where you have two almost identical images next to each other and the goal is to spot the 10 differences? Why don't you try the same game with your work before tagging it as done?

I've been on meetings where emotions are high, reviewing an implementation that clearly doesn't look like the designs, where the conversation last for less than a minute because all it takes from the person evaluating the job is to put the original design next to the developer implementation and ask "Does it look the same? Does it look like it is finished?".

And of course it doesn't. Just avoid that meeting by playing the game by yourself and prevents others from playing it for you with your work.

On a not much of a side note, I find the post "The Undefinition of "Done"" quite cool, so check it out as it might help with your development process.

Magento virtual themes or why theme changes don't show up in the front end

Magento virtual themes or why theme changes don't show up in the front end

You have a Magento 2 theme created (at least you can see it in your IDE and we're going to assume there's no typo in the theme.xml nor in the registration.php), you can also see it in the Admin, and finally you have it configured for your store.

Then you go to the front end and you see a Frankenstein's monster: the CSS is okay but the Layout XML is not being taken into consideration. The front end kind of knows which theme to load, but it's loading it only partially.

What it's going on? How do we fix it?

One of the possibilities is that the theme is set as Virtual instead of Physical in the database, causing behaviors such as the described above.

Magento 2 happen to have 3 types of themes, of which I have found very little information in the official documentation (just a minor mention in the Troubleshooting section of the 2.0 "Apply and configure a storefront theme" page but gone in the 2.2 version of it) but a convincing explanation in this StackExchange question.

We have "Physical themes" which are the well-known themes such as Blank and Luma, second we have "Virtual themes" which appears to be themes that extend a Physical theme but doesn't exist in the files (nothing in app/design), and finally we have the "Staging themes" which I have no idea what they are nor how they behave (sorry).

These 3 different types of themes are defined in the Interface Magento\Framework\View\Design\ThemeInterface as 0, 1, and 2 for Physical, Virtual and Staging, respectively.

If you go to your database (using the Terminal, PhpMyAdmin or an app like TablePlus) and take a look at the theme table, chances are that you'll find something like this:

If you encounter a 1 in the type column for your theme, there's your problem. Change it to 0 and everything will be fixed.

How the theme became Virtual without anybody setting it anywhere?

You're probably wondering how that 1 ended up there without anybody setting it (at least you're sure you didn't as you just find out about all this).

As described, Virtual themes are themes that doesn't exist in the code, meaning there are no files for that theme (how Magento expect us to use this type of theme is for me unknown).

If you're using a version control system such as Git maybe (maybe) you ended up for a moment in a branch without the theme files and somehow loaded the front end or ran a bin/magento command. For a moment only, Magento saw in the database that a theme is set and active but found no files in the code for such theme, so it changed it to Virtual.

How a VTEX developer looks like from a technical point of view

How a VTEX developer looks like from a technical point of view

If you happen to be on a similar position as I am where one of my task is to conduct interviews and vote on someone getting hire or not, you also have to be able to establish if that person can work with a specific platform.

It is not the same working on a VTEX store, an ORO implementation, or in a Magento project. For each platform you have to have a specific set of skills, and again, depending on the platform, more experience on some specific skills are necessary and the seniority on a specific ability vary when you change the CMS you are messing with.

VTEX requires a front end developer with a signed certification from his mother saying that he's great with those "Find the n differences" puzzles you get on the Sunday's newspaper, because the primary task he'll face is to transform a given design into "code", as pixel perfect as it can be.

So, how it looks like now?

Translated to actual skills, for a start it means we're looking for someone very good at xHTML, CSS (and/or any CSS preprocessor like SASS or LESS), that can also handle simple JavaScript logic or jQuery for basic UX interactions.

Bear with me if you not agree on that "simple JavaScript logic" statement, because there's a reason why I said "for a start". With this specific developer you are kicking off the team you need for a VTEX implementation but you are not finish yet.

Based on my experience, someone with the ability to handle the layout will cover a high percentage of what the project needs. Seriously, even on highly custom VTEX projects always the largest amount of workload falls on the person who handles the implementation of the designs and that's why is very important to have someone who nails this task.

The next step is to choose between two options: we either look harder for a person with the mentioned skills that can also handle the logical part of a development, or we get another team member for this job only.

If we go for the first option, now finding the developer became a little bit more complicating.

I think that considering a lot of front end developers, on one end we have the "developer who handles the layout and leaves the logic to back end" and in the other side the "kind of full stack developer hungry for programming but with no love for the look and feel".

Our first option requires us to find someone in between, and that's hard (talking, again, from my work experience). Personally I'll go for this option, because, personally, I feel more comfortable with those "in between" developers. But that's just me.

The second option is more suitable when looking at this from a company level where you have multiple VTEX implementations.

Imagine an scenario where you have three VTEX projects ongoing, each with a person assigned full time implementing the layout only, and a fourth developer jumping from VTEX 1, to VTEX 2 and VTEX 3 working on the customizations only, while leaving the "make this as the designs indicate" to the full time assigned coworker.

The person in this second option needs to know JavaScript for real, because all VTEX front end custom stuff always falls on the need of use of JavaScript.

The developer, sort of acting as a back end developer in this platform (in a manner of speaking) will be dealing with the logical part of the implementation like struggling with the APIs and integrating with VTEX's Master Data.

But how it will look like in the future?

The platform is evolving constantly and it is on its peak on what updating the technology stack refers. This means that what I just said above still applies, but we need to consider what is coming.

In the not so distant future the idea of VTEX IO as the VTEX's web application development platform is that custom (and useful) customization that takes places on a specific VTEX store become an App, in a sort of plug and play plugin for that specific store and others.

For example, let's say you have to development something to get the users' email using a form in order to subscribe them to the newsletter configured using MailChimp. Do it once, make it an App, and reuse it on the future or sell it to other existing stores seeking for the same functionality.

In this new world, besides the fact that you need a little bit of npm and the use of a Terminal to set up your workspace, you'll definitely need to know React and GraphQL in order to build the application.

So don't get sleepy.

About how hard it is to find a front end developer capable of work with Magento

About how hard it is to find a front end developer capable of work with Magento

Is it hard to find someone willing (and able?) to work with Magento. And I'm not talking about finding an already "senior" Magento front end developer with n years of experience with that eCommerce platform and/or working in that specific field already.

No. What I mean is that it is difficult to find someone who is already a front end developer but never worked with Magento. Will he be able to? Will he understand and like the platform? Is he willing to despite what he says during the interview?

I already wrote an article about how to interview a front end developer, and I'm not sure if I strengthened enough the idea of it being a kind of a bet.

How to interview a front end developer and not die in the process
Being an interviewer it’s not an easy task as the candidate’s chances of getting the job depends not only on the candidate’s technical skills but also on the ability of the interviewer to rule on the truth of those said skills in a 60 minutes talk.

In this scenario we're betting twice as we not only need to discover if the person being interviewed possesses the skills to be a good developer but also if he or she can perform with the specific platform.

That fuzzy line between back end and front end within Magento

I encountered a lot of different "profiles" while interviewing. While the spectrum is really broad let me summarize this into two groups (nevertheless, not sure about the names I'm giving to them, but bear with me):

  • Web designers, or people focused only on the HTML and CSS (maybe jQuery?) part of the coding process. People whose main task is to convert a given PSD file into "a web".
  • Developers using the "hard tools" for coding complex logical solutions with, and not limited to, JavaScript and all its modern flavours.

The first group is excellent in that PSD to xHTML conversion process but they sort of depend on somebody to add the functionality to their creations, and the later group fails when the QA team compares what they delivered with the original design files.

So, someone in between, right? Right. But why?, because of that fuzzy line between back end and front end within Magento. :)

It depends on how the company you work for is structured, and how the roles for back end and front end are implemented there, but under my experience I can tell that none of these groups that represents the two extremes of the wide range of developers I interview can work with Magento, or at least they can't on their own as they will always lack what the other groups knows... and we need both on the front end side of a Magento project for it to go live.

Again, under my experience, while working with people that falls into this two categories I either faced the problem of things looking good but not working as expected, or things that do what they're are supposed to do but with so many differences when I open the designs (and if you are thinking "it's only colors", think responsive web design).

How we find that "in between"?

Spoiler alert: I don't know for sure, but I can tell you what I'm doing right now and hopefully it will help you achieve the same as I'm looking for if you're conduction interviews.

I recently had a meeting with somebody from the recruiting team at the company I work for in order to polish the "mechanism" to identify people too attached to the mentioned groups in order to dismiss them at the beginning of the process, and there are a lot of hints in the candidate's CV that you can use.

Exhibit A is this imaginary resume that includes skills such as HTML, CSS, SASS and jQuery, which is excellent because we need those skills. Following we find a lot of background experience building corporate websites only, but never using a CMS as there is no mention for WordPress, Joomla, Drupal, or similar.

Finally, the work experience is a mix of marketing and design, mostly a transition from the later to a developer. The court rules guilty for being too much of a member of the web designers group.

A second example is this also imaginary resume that includes all the fancy words I already used to, such as Angular, AngularJS, React, VUE, Node... you name it... and a background experience that mostly includes working on the back end side of some sites.

I don't have to tell you to which group this imaginary candidate belongs to.

So, again, someone in between. Find that resume that have a mix of the trending topic's keywords for the first and second group, and you got yourself a feasible Magento front end developer. Or work the other way around: burn the resumes that falls into the extremes and what lays in the middle is the people you should interview next.

No group is better than the other

Don't get me wrong... or let me clarify.

I do not think one group is better than the other one, and if you belong to the first one there's no obligation to learn what the other group knows, neither the other way around.

Let me put another short perspective into this: if the company you work for (or the company you applied for, or your company if you happens to have one) really separates this two groups into really two separates job positions, and if you only have to worry about the PSD to xHTML thing because somebody else is handling the functionality... good for you, and go for it, as again this depends on the scenario you're standing.

That's why I mentioned something about the way a company is structured before, because in some places you might not need to worry about the "in between" as it doesn't apply.

Happy hunting.

Check if a user has made a purchase on a VTEX store

Check if a user has made a purchase on a VTEX store

There's no a simple built in functionality on VTEX that allows to check if the current user browsing the store has already made a purchase there, but there's a twisted workaround to get this information.

Before actually going through the guide, this is the idea: we need to create a new attribute in the CL Data Entity that retains this information and this attribute is going to be updated on the Order Placed page doing an HTTP request to the VTEX Master Data using JavaScript.

Sounds simple? Well...

Creating the new attribute

Thanks to the VTEX Master Data API we can get a lot of information about the clients, but if he or she has made a purchase is not there anywhere, that's why we need to create a new attribute that will hold this information.

The new attribute, let's name it buyer, needs to be Boolean, and we need to grant it permissions to be read it and edit it using the API.

Attribute configuration on the Client Data Entity

All existing registered users on our store will have it in null or false until we changed it to true after a user performs a full checkout process.

Updating the attribute

After the user performs a purchase he will end on the Order Placed page that says something like "Em breve você receberá um e-mail no endereço john doe@example.com com todos os detalhes do pedido". We need to get that email from the source code of the page and using jQuery AJAX performs a PATCH in order to set the buyer attribute in true.

The problem is that we can't directly insert any piece of JavaScript code in the VTEX Smart Checkout. If you're thinking on adding the JavaScript code into any of the orderplaced-* templates, it won't work, the code won't be displayed because of security reasons.

VTEX Portal section

Here's the fun part: we need to use Google Tag Manager to insert JavaScript on that page.

GTM as our Trojan Horse

Since the VTEX Smart Checkout, as any other checkout process from any other platform, is a sensible part of the site and that's the reason why we don't have, directly on VTEX, a way to insert JavaScript code.

If we have Google Tag Manager integrated into our VTEX store it's our lucky day because that tool can add JavaScript on the page, and the idea is to give to GTM our jQuery AJAX request code.

To accomplish this we need to create a new Custom HTML Tag where instead of HTML we are going to add our script. This script.

$(window).load(function() {
    if ($('.orderplaced-sending-email strong').text().trim()) {
        var urlProtocol = window.location.protocol;
        var apiUrl = urlProtocol + '//api.vtexcrm.com.br/storename/dataentities/CL/documents';

        $.ajax({
            "headers": {
                "Accept": "application/vnd.vtex.masterdata.v10+json",
                "Content-Type": "application/json"
            },
            "url": apiUrl,
            "async" : false,
            "crossDomain": true,
            "type": "PATCH",
            "data": JSON.stringify({
                "email" : $('.orderplaced-sending-email strong').text().trim(),
                "buyer" : true
            })
        });
    }
});

Next, on the Fire on step, click on More in order to create a new trigger. The new trigger needs to be a personalized event that will be fired on "orderPlaced".

GTM new Tag

Save the tag and publish the changes on Google Tag Manager. This is not affected by VTEX cache so we should see the changes immediately.

At this point every time a user hits that page, meaning every time an user finish a purchase, the buyer attribute will be set to true. So now in any other page of the store you can use the VTEX Master Data API to check if buyer is true. If so, then the user browsing the site already made a purchase and you can do whatever you want with that information.

Waaaait

This is a delicate move. You are inserting JavaScript into the checkout process so test it very well, you don't want to screw this part of the VTEX implementation.