Do not forget about the emotions while selling something

Your product, service, software... whatever is the thing you're selling, it can be the hero of a story where there's a problem your potential customer has. The problem is the villain in the story, reveal it, then introduce the hero to your customer so they lived happily ever after.
3 min read
Do not forget about the emotions while selling something

I'm selling two newest iPhone, Space Gray color, both with 256 GB of capacity. When I bought them I wasn't sure about getting the 64 GB version or the bigger one, but I made up my mind in favor of the 256 GB version and I'll tell you why it was a great decision.

Last year I went on a family trip with my mom and sister to a Brazilian beach where cellular signal wasn't available all the time, meaning LTE was a luxury, and also finding WiFi was a Tom Cruise's "Mission Impossible" remake possible plot.

In this scenario, the idea of today's about everything being in the cloud and not in the physical devices was a no go for me.

The trip was beyond great. I spent a lot of time in the water with my sister trying to record the best slow motion videos: sometimes trying with just the water, sometimes filming the sand to see if that improves the video, then letting my sister try some tricks in front of the iPhone camera over and over again until we get something good.

At the end of the day we ended up with many many GB of videos, and a job not done yet. Before dinner, all nights, and most of the times waiting for our mom to get ready, we selected the best shots in order to create a video, cinematic music included, to show to mom as if we were two Directors showing the final cut of a Hollywood movie to a film criticism.

The other phone, while exactly the same, it was just used for some work stuff. It's a great device for reading emails, writing emails, and taking notes.

The difference lies in the emotions

While both are the same technical speaking, they are not the same emotionally speaking. If I still need to prove my point I'll will continue telling you fake stories including a beach, a mom and a sister until your eyes get wet and you rip this phone out of my hand while letting me keep the one used for work... because that's the whole point.

I know it's very obvious I'm appealing to your emotions in the last story, but the true is that we're all victims of this trick in a regular basis.

Think about it. Think about the last time you bough something on Amazon, eBay or Mercado Libre, when you searched for a product you already knew, ended up with three or four browser tabs with similar publications of the same product, different price within a short range, and then you made a decision from where to buy based on not much logical data but confidence on the seller, the aspect of the website, the fact that one had a better description with a video of real people using the product, the fact that one had reviews from previous buyers.

Think in Coke showing a couple jumping of a cliff into a lake, McDonald's showing a single mom with his kid laughing while eating fries, a perfume showing a good looking guy with three Victoria's Secret angels.

I remember a local ad I often see on TV showing a divided screen where on the left you can see a cute lady getting ready to go out on a sunny day, and on the other side a big man wearing a hood and preparing his tools to break into the house of this lady the moment she step out. There you have the victim, the villain, the conflict... and the hero? A trustworthy armored door at an accessible price.

And Apple?, oh, boy, those guys really know everything about selling feelings instead of products. I remember during an Apple's Keynote somebody, probably Tim Cook, introduced "Live Photos" (you know, that feature that records a few seconds before and after an static photo) and said something like "This feature allows you to see a photo, gently press on the screen, and get a sneak peak of what was going on during the shot of that static image".

A time machine that shows you 3 seconds of video and audio around the static shot. Right in the feels.

What you're selling is a hero

Your product, service, software... whatever is the thing you're selling, it can be the hero of a story. A story where there's a problem your potential customer has.

The problem is the villain in the story you need to start telling. It can be pretty obvious like in the ad for the armored door, or very subtle like in the McDonald's ad where they tell that they know how hard it is to being a single mom but still you can come upon great moments with your son in their stores.

Spot the villain, disclose the problematic, then introduce the hero to your customer so they lived happily ever after.

A blank Ghost blog theme for development

The Pale Ghost theme is a blank theme, developer ready, focused on the markup without styles, that already includes all the Ghost features for you to customize or remove in order to create your own theme.
2 min read
A blank Ghost blog theme for development

This blogs runs on the Ghost platform built with Node.js, with a homemade theme that uses Handlebars, HTML, CSS and JavaScript, and if you are reading this article chances are that you're already a Ghost blog owner and that you're looking to develop your own theme.

The problem with the Ghost default theme named Casper, while it's extremely helpful to learn how to develop a custom Ghost theme, is that it is too complex or "it has too many things" you probably don't want for your blog.

For example, when creating the theme for this blog, I had to "deconstruct" Casper to start building on top of the ashes because I wanted a more simple theme, that has my own code wrote the way I wanted it.

Introducing the Pale Ghost blank theme

The Pale Ghost theme is a blank theme, developer ready, focused on the markup without styles, that already includes all the Ghost features for you to customize or remove in order to create your own theme.

I already searched for Ghost blank themes, and truth be told there are many out there, but none suits my desires. All the blank themes I encounter has too much JavaScript, or they are too much complex to the point they looses they purpose of being a blank theme.

This blank theme in particular is very simple, so you might be spending time in the styling part with CSS/SASS/LESS rather than working on the markup. And if you want to move stuff around, you'll find it's easy with the Pale Ghost theme as it is well deconstructed into different .hbs files for an easy development.

It also includes everything a Ghost theme can deliver, just as Casper, but with a simple implementation. The goal with this theme is to avoid the part where we as developers smack things down before actually building up.

For a more technical description of what this blank theme includes you can check the Pale Ghost theme's GitHub page.

Downloading...

You can download this blank Ghost theme from the Pale Ghost theme's GitHub page, where you'll find the "Releases" section.

Fun facts about the page speed of a website

If Amazon become 1 second slower it could cost them 1.6 billions dollars a year. That's 96 millions kilograms of premium ice cream. That amount of ice cream means that you and your future generations can enjoy a kilo of ice cream per day starting today and for the following 200 thousands years.
2 min read
Fun facts about the page speed of a website

Everybody, everywhere, all the time, is saying that page speed matters. We get it, we heard it a trillion times, and I'm not sure why we keep writing about it or discussing it.

Page speed matters as much as the sun is hot, period. If you are still in doubt then you're having a serious problem. Make your website faster, and do not argue this fact, as it will cost you money.

That disclaimer being made, you probably also read that Amazon run some test and found out that if their site become 1 second slower it could cost them 1.6 billions dollars a year. And that's 1.600.000.000 dollars.

How much is 1.600.000.000 dollars?

  • That's more than 133 millions dollars per month. An amount of money I probably never going to see in real life, at least not all together, whether you divide per months or even days (more than 4 millions a day).
  • In Argentina, that's 48 billions pesos considering the currency value by the time I'm writing this post.
  • That's 96 millions (just millions) kilograms of premium ice cream. That amount of ice cream means that you and your future generations can enjoy more than a kilo of ice cream per day starting today and for the following 200 thousands years.
  • If you buy an iPhone X, and iPad Pro, an Apple Watch Series 3... And then a MacBook Pro, an iMac Pro, an Apple TV... and finally an iPod Touch just because, you'll be spending around 20 thousands dollars meaning that for 200 years you can get yourself a brand new model of all this products everyday.
  • 320 millions Caramel Macchiato Venti from Starbucks.
  • A Magento Commerce licence could rise up to 125 thousands dollars per year based on expected annual gross sales revenue, meaning you can build 12800 new eCommerce websites using this platform.
  • The Apple Inc. v. Samsung Electronics Co. legal battle you probably read on the Internet doesn't event get near this number. Wikipedia talks about 539 millions in favor of Apple for the first US trial, and then 120 millions for the second US trial. It was pointless to check the legal battles in the other countries.
  • And my home banking doesn't let me enter 1.600.000.000 in any form's input.

It was hard to find the real source of this 1.6 billions dollars proclamation, so I'm not sure about the veracity of such statement but for the end of this post it is not 100% relevant.

What I did find is that Greg Linder, best known as the inventor of Amazon's recommendations, made a presentation in 2006 saying the following:

Every 100ms delay costs 1% of sales.
Greg Linder

Probably somebody took that statement, and calculated it to be 1.6 billions dollars a year.

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

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.
3 min read
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.

Developer's work success being too much about personality rather than hard skills

Everybody has access to the same documentation, the same in-house training programs, to everybody's code, to the same people to ask questions and to learn from... and what's set the difference between someone progressing in his line of work and someone stuck is the personality each developer has.
3 min read
Developer's work success being too much about personality rather than hard skills

When giving a performance's reviews, one idea I used to pitch to somebody with the potential to be an even better developer in the future is that we all have the same tools in the company to improve ourselves.

Everybody has access to the same documentation, to the same in-house training programs, to the same software, to everybody's code, to basically the same people to ask questions and to learn from... and what's set the difference between someone progressing in his or her line of work and someone stuck is the personality each developer has.

This is something that bothers me in the sense that it makes me feel I'm losing control of any recruiting process I might been part of, or any "technical coaching" I'm giving.

Because while it might sounds as a "motivational speech" during the performance's review, let's do not lose sight of the timeline here. If we get to that point saying is more about personality than hard skills, then it was also more about personality a few months ago during the interview process.

What if interviews are all about luck and not about us evaluating correctly the hard skills of a candidate?

Sometimes it feels like it doesn't matter if I really really prepare for an interview, or if I improve my tricks to get to really really know the candidate's hard skills, because it feels like it all goes down to about how lucky we are as a company when we take our chances with a candidate by saying "Yes, come work with us". Does it happens to you?

I remember joking about this issue by proposing something like open the company's door, let 20 candidates join us, and we'll see how they perform during a month... and by the end lets "fire all the personalities" that didn't succeed.

Let's not waste more time with interviews and technical exercises! Everybody is welcome for a month, and we'll decide later who can stay.

Yep, that would be a fun disaster to watch. But again, this is sometimes what I'm experiencing with the whole recruiting process, and also I stand corrected by saying it's not really a feeling but an actual fact because we truly accepted people with serious doubts about their hard skills that in a short time became great developers, and we also let in promising ninja developers that resulted in a total fiasco.

So, what's the next step?

I don't know.

I'm struggling with this problem and this is more of a sharing my concerns post than a post with an outstanding solution at the end. But let's do some brainstorming in order to get some action items to work on later.

Probably the first idea is that we suck at interviewing because we don't have the skills or the tools to really get to know the candidate's hard skills pass the personality and what that person is selling during the interview.

We should improve the exercises we're giving, enhance the questions we're asking, and have a clear understanding of which hard skills we are looking for and to what degree of knowledge we're aiming for those identified skills.

Before that face to face technical interview, it seems like it's necessary to improve the first informal interview to rule out the personalities we do not want. Because, don't get me wrong, we do want people objective-oriented and willing to learn everything... but that's not the only things we want to depend from.

So, it seems like this last thing is more mandatory not to solve our main problem here but to avoid a different one.

When the process fails again (meaning when we bet for a candidate and things goes wrong again) we should be doing an analysis of what happened and we should be having metrics about failing and succeeding process in order to identify what's working and what's not.

The goal here is not to all say "Oh, we fail again, let's try again one more time" but more about getting the reasons behind the process that didn't go as expected, and getting hints about how to make it better.

I still do not know for sure how to solve this, but I get myself some ideas to sleep on it and I hope you too.

Understanding the product's name front end logic in VTEX

Is VTEX showing the name from the "Product" in the Admin? Or is it showing the name we entered in the "SKU"? Or is it showing both?... or why sometimes it seems like VTEX is using the "Product" name and in other occasions it is using the "SKU" name?
2 min read
Understanding the product's name front end logic in VTEX

Is VTEX showing the name from the Product in the Admin? Or is it showing the name we entered in the SKU? Or is it showing both?... or why sometimes it seems like VTEX is using the Product name and in other occasions it is using the SKU name?

In other words, what's the name I'm going to see in the front end of my VTEX store when creating a new product?

I'm writing this down because I found there's always a confusion about what is VTEX showing as a name for a product when looking at it in the front end (like in a category or product's page) considering there's a tricky logic there that involves the Product entity and the SKU.

Product entity name and SKU name?

To avoid any misunderstanding, let's discuss first what I mean by "Product entity name" and what I'm talking about when referring to the "SKU name".

When I say "product's name" we all think about a product as a whole, the item itself and the name that item has. But a product in VTEX is divided into two thing: The Product (or the Product entity) and the SKUs included on that Product.

I know I might sound philosophical and delusional but just take a look at this screenshot so I explain myself better.

understanding-the-products-name-front-end-logic-in-vtex-01-1

Is our site showing the name from the first column or from the second one?

Which one is going to appear on the front end of the VTEX store?

It just depends on this simple logic you need to consider.

If the Product entity name is exactly the same as the SKU name, then VTEX will show only one. Take a look at the screenshot above where the names in both columns are identical, meaning the front end will only show "iPhone X 64GB Silver".

On the other hand, if the name in the Product is different from the name in the SKU, then VTEX will show the two names separated by a dash (-).

For example, if for the Product we have "iPhone X 64GB" and for the SKU we have just "Silver", then the result on the front end it is going to be "iPhone X 64GB - Silver". That simple.

understanding-the-products-name-front-end-logic-in-vtex-02

Knowing that, if you're facing the "problem" in VTEX with the front end showing the names "duplicated" or if you didn't understand from where that final name is coming... now you know.

Keeping both the Product and SKU with the exacly same text (not even a difference in the capital letters) will show only one name, no dash.

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

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?
4 min read
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

There's a twisted workaround to check if the user has already made a purchase on the current VTEX store thanks again to VTEX Master Data.
3 min read
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.

Discover on what commit a bug was introduced using git bisect

The git bisect command allows us to performs a binary search to find out what commit causes a bug. It's the fast version of going through each commit from the first one to the last one until you finds out that "Oh, after this commit the bug can be reproduced".
3 min read
Discover on what commit a bug was introduced using git bisect

The git bisect command allows us to performs a binary search to find out what commit causes a bug. It's the fast version of going through each commit from the first one to the last one until you finds out that "Oh, after this commit the bug can be reproduced".

Basically what you do is tell Git where things were working (meaning on what commit you remember the bug didn't appear), and then you tell Git where things are not working (meaning a commit where the bug can be reproduced, that can be the last one).

It's easy with an example

In theory sounds great but it's better if we go through an example to learn how to use the git bisect command.

I have a small fake project with a series of commits and I introduced a bug in one of them. Of course, the commit messages are self explanatory but we need that to see if the git bisect really works.

We are going to find out on what commit a typo was introduced on the content of my example.txt file.

Finding the commits where things works and doesn't

This is the easy part and you probably know how to do it.

Checkout to an old commit, see if the bug disappeared, write down the commit hash, and come back to the HEAD. And you can use the newest commit hash as the bad point.

Here's the list of my commits and the one I choose for the good and bad points.

commit 9cc1e21a4422a3e1365bd04b616ddafd98475c3e
Improved ways to contact us.
(here things are bad)

commit 785361159507faa755dfb4a1aaaac8cb7ad18c7e
Added more text to encourage people.

commit 5603f08930ad4aaf84843f6205f25cdd0f684f4f
Added a signature.

commit 45493f69eba7153d7d954f0eeb7e4973e32d9f3a
Added a way to contact us in case he/she finds a typo.

commit 9487c88848e056f120166e0a5844822cb0f6b8a4
Added even more text to the example.txt file to encourage the user to report any typo.

commit c04e336490796f22423b9685c0ffe745ebcddcbb
A wild typo appears...

commit 2fec0d56c80fd1f7f000ab31ecba643d4c12533d
Improved example.txt file by adding more text to it.

commit 979ba26a9e0eaeae35e0e236bc14126708a942a6
Updated example.txt file with some text without a typo.
(here things are good)

commit 27c9d5ec2bcae6f1aa8ee295483ac9696e579296
Initial commit with example.txt empty.

Indicating the commits where things works and doesn't

You have the good and the bad, let's transfer that knowledge to Git.

git bisect start
git bisect good 979ba26a9e0eaeae35e0e236bc14126708a942a6
git bisect bad 9cc1e21a4422a3e1365bd04b616ddafd98475c3e

Bisecting

Git will move you to any of the commits trap in the middle of the good and bad points. And the only thing you need to do is to tell Git if that commit is a good or a bad one, meaning if you can reproduce the bug or not.

Here's what I get:

➜  Bisect_Project git:(master) git bisect start
➜  Bisect_Project git:(master) git bisect good 979ba26a9e0eaeae35e0e236bc14126708a942a6
➜  Bisect_Project git:(master) git bisect bad 9cc1e21a4422a3e1365bd04b616ddafd98475c3e
Bisecting: 3 revisions left to test after this (roughly 2 steps)
[9487c88848e056f120166e0a5844822cb0f6b8a4] Added even more text to the example.txt file to encourage the user to report any typo.
➜  Bisect_Project git:(9487c88)

I check the example.txt file to see if the typo is there or not.

This test hat no typo. Please, feel free to check it.

If you find a problem, please report it.

Is there (it says hat instead of has), so it's a bad commit. I tell Git about it and he move me to anothe commit.

➜  Bisect_Project git:(9487c88) git bisect bad
Bisecting: 0 revisions left to test after this (roughly 1 step)
[c04e336490796f22423b9685c0ffe745ebcddcbb] A wild typo appears...

I check the example.txt file again.

This test hat no typo. Please, feel free to check it.

The typo is there, I tell Git about it and he'll move me again.

➜  Bisect_Project git:(c04e336) git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[2fec0d56c80fd1f7f000ab31ecba643d4c12533d] Improved example.txt file by adding more text to it.

I check the example.txt file one more time.

This test has no typo. Please, feel free to check it.

No typo! It's a good commit.

➜  Bisect_Project git:(2fec0d5) git bisect good
c04e336490796f22423b9685c0ffe745ebcddcbb is the first bad commit
commit c04e336490796f22423b9685c0ffe745ebcddcbb
Author: nahuelsanchez <nsanchez@summasolutions.net>
Date:   Fri Feb 19 22:52:04 2016 -0300

    A wild typo appears...

:100644 100644 5aebed1a496b67a06fe93b31d9590eae6fb258ad 657a182a496be92d26c948ece9cd9fa0061e03bb M	example.txt
➜  Bisect_Project git:(2fec0d5)

And there we have it. Git is telling us on what commit the bug appeared for the first time. It's up to your skills to check the code and fix it.

When you want to return to the HEAD just do a git bisect reset and you'll be back.

Code to GET, POST, PATCH and PUT data in VTEX Master Data

Working jQuery AJAX requests ready to be used to GET, POST, PATCH and PUT data in a specific Data Entity to simplify the interaction with the Master Data.
3 min read
Code to GET, POST, PATCH and PUT data in VTEX Master Data

We can manipulate the documents existing in the VTEX Master Data using HTTP request, and it's like the most important thing we should know to dominate this platform's tool.

The official Master Data API documentation breaks down the different HTTP request we can use and explains each part of the request but this information wasn't enough for me to create a working code.

Using and old technique known as "try and failure" I came up with four working jQuery AJAX requests ready to be used to GET, POST, PATCH and PUT data in a specific Data Entity.

Differences between POST, PATCH and PUT in VTEX Master Data
There are small differences between POST, PATCH and PUT that justify the existence of all of them, and knowing this could improve our VTEX implementation.

My goal was to simplify the interaction with the VTEX Master Data during the implementation of a VTEX store. The code is far from perfect but it's a working start.

GET

function getFromMasterData(name, where, fields) {
    var store = 'storeName';
    var urlProtocol = window.location.protocol;
    var apiUrl = urlProtocol + '//api.vtex.com/' + store + '/dataentities/' + name + '/search?_where=' + where + '&_fields='+ fields;
    var response;

    $.ajax({
        "headers": {
            "Accept": "application/vnd.vtex.masterdata.v10.profileSchema+json"
        },
        "url": apiUrl,
        "async" : false,
        "crossDomain": true,
        "type": "GET"
    }).success(function(data) {
        response = data[0];
    }).fail(function(data) {
        response = data;
    });

    return response;
}

The first parameter here, name, refers to the Data Entity's acronym (for example, CL for the Client's Data Entity) and it's the same for the next HTTP requests.

The second parameter, where allows us to define the filter to use while requesting the documents from the Master Data. For example, email=johndoe@example.com.

Finally, fields is there to specify what attributes we want to retrieve from the results.

Here's an example to retrieve the first name and last name from a client knowing its email address.

getFromMasterData('CL', 'email=johndoe@example.com', 'firstName,lastName')

POST

function postInMasterData(name, email, fields) {
    var store = 'storeName';
    var urlProtocol = window.location.protocol;
    var apiUrl = urlProtocol + '//api.vtexcrm.com.br/' + store + '/dataentities/' + name + '/documents';
    var response;

    var who = {
        "email": email
    };

    var data = $.extend(who, fields);

    $.ajax({
        "headers": {
            "Accept": "application/vnd.vtex.ds.v10+json",
            "Content-Type": "application/json"
        },
        "url": apiUrl,
        "async" : false,
        "crossDomain": true,
        "type": "POST",
        "data": JSON.stringify(data)
    }).success(function(data) {
        response = data;
    }).fail(function(data) {
        response = data;
    });
    
    return response;
}

In this case, email needs to be an actual email address that the code is going to use as an unique identifier of the document that is going to be created on the Master Data, and fields is a JSON object with the attributes and values to send in the request.

Life is better with examples.

var someAttributes = {
     firstName : 'John',
     lastName : 'Doe'
};

postInMasterData('CL', 'johndoe@example.com', someAttributes);

PATCH

function patchInMasterData(name, email, fields) {
    var store = 'storeName';
    var urlProtocol = window.location.protocol;
    var apiUrl = urlProtocol + '//api.vtexcrm.com.br/' + store + '/dataentities/' + name + '/documents';
    var response;

    var who = {
        "email": email
    };

    var data = $.extend(who, fields);

    $.ajax({
        "headers": {
            "Accept": "application/vnd.vtex.masterdata.v10+json",
            "Content-Type": "application/json"
        },
        "url": apiUrl,
        "async" : false,
        "crossDomain": true,
        "type": "PATCH",
        "data": JSON.stringify(data)
    }).success(function(data) {
        response = data;
    }).fail(function(data) {
        response = data;
    });
    
    return response;
}

The parameters here works just as the POST's example, where email is the way to identify the document is going to be edited and fields the JSON object with the attributes and values, as show in the following example.

var someAttributes = {
     firstName : 'John'
};

patchInMasterData('CL', 'johndoe@example.com', someAttributes);

PUT

function putInMasterData(name, email, fields) {
    var store = 'storeName';
    var urlProtocol = window.location.protocol;
    var apiUrl = urlProtocol + '//api.vtexcrm.com.br/' + store + '/dataentities/' + name + '/documents';
    var response;

    var who = {
        "email": email
    };

    var data = $.extend(who, fields);

    $.ajax({
        "headers": {
            "Accept": "application/vnd.vtex.masterdata.v10+json",
            "Content-Type": "application/json"
        },
        "url": apiUrl,
        "async" : false,
        "crossDomain": true,
        "type": "PUT",
        "data": JSON.stringify(data)
    }).success(function(data) {
        response = data;
    }).fail(function(data) {
        response = data;
    });
    
    return response;
}

More of the same, just like the last two codes. And a similar example.

var someAttributes = {
     lastName : 'Doe'
};

putInMasterData('CL', 'johndoe@example.com', someAttributes);

This is on GitHub

I decided to put this snippets on a Git repository you can find in https://github.com/nahuelsanchez/vtexmasterdataapiconnection.

Feel free to send any improvement you think this code desperately needs (thanks in advance).