Nahuel Sanchez

A place to write down what I discover and learn everyday at my workplace. Front-end may be the main topic, but who knows, probably I'll be publishing something else.

You're looking at all the posts published by Nahuel Sanchez.
← Go back to the front page

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

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

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.

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.

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.