Forem: Diego Eis

Good practices for JAMStack projects

Diego Eis — Wed, 09 May 2018 14:03:44 +0000

The revolution of websites using an architecture based on JavaScript, APIs and a pre-generated code is called JAMStack. This way to do websites have the objective to relieve the architecture to maintain websites or systems. Take my website for example Tableless.com.br. In there we had maintained an architecture based on Wordpress, this means that we need to have a MySQL database... basically a LAMP architecture. In this way, for sake of organization, we maintain this architecture in two different droplets in DigitalOcean. Today we take off the Wordpress and the Website is all made using Hugo, hosted in Netlify, with the code on Github.

This is not a hard thing to do, but exist some good practices that you can follow to make easy your way.

Use CDN

This is not a required (by the way, none of these topics is), but behind your website is already very light due to the loading of pure static HTML files, it could be improved if we use a CDN. The projects based in JAMStack don't need to server-side code or something like that, they could be distributed more easily.

The most popular CDN is CloudFlare, but there exist a lot of other services that you can put your assets in there, but usually, they already give the most popular JavaScript frameworks and libraries to you use in your projects. Some links:

All the code live in GIT

This is life rule. Today is not normal to see teams that don't use some kind of code version service. The GIT is the most popular and we know a bunch of services like GitHub that make all the hard job to us. In JAMStack projects, anyone needs to download and rune the code on your own machine in minutes. Install databases in many environments, run up the dependencies and so on is not needed. The simplicity of the static stack reduces to almost zero the friction of contributing to projects based on the JAMStack idea, plus we make simple the test and staging workflows.

Build tools

Depending on the project, it is interesting to use a build tool. The idea is that all the process need to be automated. The result will be static HTML, CSS and JS files, but it need be built following the good practices. You can use all that good stuff: pre/post CSS processors, use WebPacks and regulars task runners like Gulp, Grunt, Babel and whatever you like to use to make your build life easier.

Here we basically use only SASS to deliver the CSS and nothing more. We don't have a lot of JS that we need to minify the code. The images are hosted in imgur. The static files generation is made by Hugo. So, I dismiss anything that could bring more complexity to the project. Today, we have more than 1800 articles and posts to build. This takes 5 minutes to build in production, using Netlify.

Automated Builds

Because the JAMStack project is made with pre built code, when we change the content or the interface, this updates will not go to the product until you run the build process. When you upload new code to your repository, your environment needs to know that, to make the build of files and publish automatically your project. I know that exist many services to do that, but all them are more complex exactly because most regular projects depends on some kind back-end language. In a simple JAMStack website, you can make your own webhooks or use some service that gives this feature to you, like Netlify.

Atomic Deploys

Atomic Deploys are deployed where all the system just go to production when the upload of all modified files is ended. It is common to make several changes, either content or interface, needing to make deploys of several files. Until you upload each of the files, there may be a time of inconsistencies until the upload process is finished.

Imagine that: the new HTML code was uploaded first than the CSS, in a brief moment, the layout will break. This can happen all the time depending on the frequency you make changes.

Cache invalidation

We are talking about static files. It is common to have problems with the cache. Cache is the bad and good things of the web. In this case, we have to be sure that the environment is invalidating the cache, especially if we are using a CDN. You need to be sure that the browsers will download the new files.

The Netlify (no, the Netlify is not paying me to say all that) has a feature called Instant Cache Invalidation, that invalidate the old cache without any work.

Conclusion

A lot of what I said are things that we make in our regular days. But, usually, we do that to make easy just a part of the project. But, I already knew teams where the front-ends need to build your assets before pushing the code because the existing workflow does not build this kind of file. When we talk about a project that has light architecture like the JAMStack propose, we can't add manual tasks, but, we can not automate everything to the point of making the project complex.

Obviously, a JAMStack project cannot be compared with complex systems. I'm talking about most websites the live on the internet. Personal little blogs, personal websites, company institutional websites, etc... Here in Brazil, I've seen discussions in companies that want to make their websites using React. What the point here? We need to learn to use the right tool to the right problem. Start small. During a long time, the first answer when we need to create a website was "Use Wordpress". But the technology to make websites already exist a long time before, it is called HTML.

6 tips to succeed in freelancing and remote work

Diego Eis — Thu, 02 Nov 2017 15:00:22 +0000

Oppositely to what many believe, remote work and freelance projects are not easy. I know it's everyone's dreams to stay at home, organize their own hours to go to the park (see a movie, go to a beach, sleep more etc etc etc) while everybody kills themselves in an office.

To have this privilege, you do not have to be just good at what you do, you need to be responsible and have extra disciplines that go beyond your technical responsibilities.

When you need to set up a remote company or find a freelancer to do a project, this means you will find great professionals spread over the world. But, this professional would have to be good not only in your technical specialties, they need to have a good sense of collectivity and a lot of empathy. They do not just think about their task, but also the task of all other project members, including the client side, who is usually concerned about the progress of the project.

Here are some basic tips for not being a fiasco when you work remotely or get a freelancer remote job:

1. Give status

When working from the same office you have the whole team working by your side all the time but that's not true for the remote environment. When working remotely, you will not find the whole team working at the same time.

In a non-face-to-face team, status is what makes things not get off the ground. You must give and receive project status all the time. Whether by email, WhatsApp, Telegram, morse code or smoke signal. You need to give news and this news needs to be frequent. Slack is good but it is not enough. Usually, in teams that have people all around the world, is not easy understand the flow of messages sent in a different hour.

Just look the PR descriptions and commits messages is not enough. The team and the person who interacts with the customers need to know EVERYTHING. Although your commit is incredibly detailed, this is not enough. You need to talk to the team and tell them exactly what your status is on the project. The list of tasks done and the list of commits will be the support, but what will really make them safe and informed are their words.

If you do not like to give status, forget it, you are not good at doing remote work. If you do not like emailing in detail on where your work is when you will take the day off, give it up, this is not for you. Even in these days, you will need to keep in touch.

Usually, status can be given 2 times a day, in the morning and in the afternoon. If you make a long stop during the day, it is good to keep the team informed as well. But usually a mid-morning and a late afternoon report is essential so someone can touch the client news of everything is going.

2. Never omit information

But, suppose you don't need to give news all the time, in these case you can't, under any circumstances, omit or forget information. When someone asks you the status of the task, do not worry if it is incomplete, say exactly the current status. Do not try to tell good news when you don't have good news...

If you're missing a piece of functionality, say so. If you forgot to do something, say so. If you drank until you fell the night before and you will not be able to work, say so (you do not have to say everything you did when you were drunk...). But never, by any means, hide any kind of information.

If you simply hide information, the emergency decisions, which are the most important decisions, will be totally wrong.

This information will also be used to indicate a more suitable status for the customer. If you are a freelancer, choose to be very sincere with the client. I'd rather lose the client by telling the truth than by giving some excuse. I prefer to stay sane to finish the other projects that remain, then distressed and crazy trying to invent an excuse for the client.

No money pays for such a headache.

3. Keep the project repository always up-to-date

NEVER, NEVER, NEVER stay long time away from your computer before commit and push your code. Do you wanna go to the park and run with your dog? Update the repository.

Delaying a project because you did not update the repository is a very wrong thing. Especially when your tasks affect the tasks of the team. This is a mistake that can cause a terrible headache for the whole team.

Just to make it clear: I'm not saying that you have to upload incomplete tasks. You only upload completed and revised tasks to the repository. However, if you are working on a separate branch dedicated to a given task, upload everything you can and tell the team that a particular branch has an incomplete task, but always leave that branch up to date. Someone can eventually continue your project from where you left off. If this happens and you have not updated the branch, someone will have problems.

4. Bad news is better than no news

If you are a freelancer, you need to give bad news sometimes. Ahhh, the bad news. The bad news is normal in internet projects. But having no news is worse. The client becomes desperate, stressed and begins to doubt of your ability. Problems happen. We are talking about software development, that is, problems will always there.

Nobody likes to get bad news, but everyone like to get the good news of your project. The client needs to know what is happening, don't worry if this is good or bad news, but the client has a schedule to follow with other teams like marketing, support, commercial and so on... When you don't give any news, even the bad news, you affect the progress of the project and other people involved.

Remember that: the problem is not given bad news, the problem doesn't give news at all.

5. Freelancer: don't get a project if you think you will not finish it in time

Don't matter the reason, don't accept the job if you know that you will don't have time to finish it. I know that you are thinking: "but I need the money... I want to travel the world and this money could be useful..."
But is better lose a client now, or have to give excuses (remember bad news?) later?

In this case is better, to be honest, and say that you don't have time to hold his job. Never dismiss a client without a good and real reason.

The client will not mad at you. He can even think you are a good freelancer because you are being fully honest, and if this happens, he will wait (if be the case). The NO is your friend.

6. Be responsible

If you have responsibility and course, commitment, you will be fine. The problem is that many devs and freelancers simply lose great opportunities and to me, this has a simple name: irresponsibility.

You have a job to deliver and exists people that count on you to deliver this job. These people trust in your professionalism to get that job done. They pay a lot of money to you. You don't have the right to screw up all the plan because you are irresponsible with all the points exposed in this text.

But no one is perfect and time to time you will break some rule. It's all right. When you do that, say sorry, move on and try don't break anything again. People think that technical knowledge is enough, but it is not. You need to work hard on soft skills like you work on hard skills. This is a simple thinking. You need to have empathy and know how your actions will affect the client and the team.

What do you think about the points of this article? You agree with that? Did you pass through similar problems? Let me know if this was useful to someone.

The (probable) end of the front-end profession as you know it

Diego Eis — Tue, 05 Sep 2017 23:28:20 +0000

A regular and common web development process can be divided into three major categories: design, front-end and back-end. In my opinion, the front-end has the most manual and repetitive processes.

Think about it, the core of the front-end job is summed up in two parts:

Layout implementation: create the first code of project where we replicate the layout designed in some graphic app, to static HTML, CSS and JS code;
API integration: after (or at the same time) the static code was made, the interface is integrated using an API, which usually carries a lot of logic, since the same API is used to feed other platforms such as mobile, robots, web version etc;

The other responsibilities that orbit around the front-end like accessibility, SEO, performance, compatibility between browsers, semantic code, among other things that you may judge to be the responsibility of a front-end are a mere preciosity. They may or may not exist in a project. But a project does not survive without the front-end code of the layout and without the content integrated into interface.

Today already we delegate a bunch of repetitive manual tasks to tools to save some time, automating the front-end workflow. Just to cite a few tools soups:

CSS Preprocessors: Sass, Less, Stylus
Scaffolding: Yeoman, Slush
Dependencies / Module Bundles: Bower, NPM, Yarn, Webpack, Duo, RequireJS, Browserify, JSPM, Rollup
SPA / Libraries / Frameworks: React, Angular, Vue.js, Backbone, EmberJS, todomvc, Polymer, Lodash, Aurelia, MeteorJS
CSS Frameworks / Libraries: SemanticUI, Bootstrap, Foundation, UiKit, YUI, Susy
JS Test: Mocha, Jasmine, QUnit, Ava, Tape, Jest
JS Templates: Underscore, Mustache, Handlebars, DoT, Dust, EJS

But even with all these tools, the core of the responsibility of a front-end remains to implement the original layout and integrate the interface with the back-end. You still continue to replicate the layout that someone spent days designing and integrating content of an API that someone else created. Your day comes down to switching between the windows of Sublime / Sketch / Browser / Sublime / API / Browser / Sublime.

“Automation is not about being lazy. It’s about being efficient. — Addy Osmani

This process becomes tedious and the requirements to try to make efficient front-end work only increases. Every mechanical, repetitive, and manual task tends to be automated and in my opinion, very soon, we will not need someone running end-to-end front-end work.

Okay, breathe. That is my opinion. Since the front-end is the most operational part of the whole process, sooner or later all (or a lot of that) work done on the front-end will be automated, even these two major tasks. However, they may already have their days counted.

Working with real data direct from Design

You may not be a designer, but there is a premise in the world of designers that says you should always work with real content. That means deliver layouts with text using Lorem Ipsum Dolor is something of a junior designer.

“If your site or application requires data input, enter real and relevant words and type the text, do not just paste it in from another source. — Jason Fried

The idea is to create a layout as accurately as possible using the terms, words, names, dates, etc in order to get closer to the user experience.

Currently, most of the visual programs used to create web layouts have some feature or plugin that allows integrate with some data source that contains real content.

For example, Sketch, which is the most beloved visual creation program of the moment, has plugins that allow direct integration between API and layout. See for example the video below demonstrating the use of the Craft plugin:

Watch this demonstration that uses the Stackoverflow API:

The point here is: we just need to create the layout once, using the tool of choice and that’s it. We do not need a person to re-implement this layout with HTML, CSS, and JS manually. This leads to a second discussion: even with the design ready and using real data from an API, we still need it to be accessible by browsers.

How that idea of “Design in the Browser fits here? This proposed process is actually created to avoid the work of producing the same layout twice, but it is much better to make a design using a visual program than to write direct in the code. IMHO.

Beautiful code is not important

The front-end developers always hated code generated by tools like Dreamweaver. They have a reason for it: the code is usually unmaintainable. It was a time where the internet connection was precarious and everything we could do to improve site performance, we did. The code generated by Wysiwyg apps had several problems: it was difficult to humanly read, with poor semantics, it contained useless code and it was often not compatible with all browsers or screen resolutions. All of these made us value clean, semantic, lean and accessible code.

A clean code in the web became a synonymous of good ranking on Google searches, a good cross-browser compatibility, a load performance, better productivity among team members, better maintenance, and so on.

Most of these problems are now solved:

Browsers have a better compliance with web standards, solving most of the cross-compatibility issues;
The performance is improved on several fronts: the build process of assets, technologies like HTTP/2 and even the evolution of the internet connection;
The maintenance and readability of HTML / CSS code is no longer a major concern, since HTML is easily written using few semantic tags and CSS has preprocessors, which help a lot when it comes to setting standards, as well as good practices;
JS is well advised by frameworks, libraries and a series of good practices that take responsibility for the heavy part of the work, leaving little room for errors from devs;
And the most important thing for me is that the semantics is no longer in HTML. Since of technologies like JSON-LD, the semantics is no longer tied to the HTML code and this is great;

I know that even giving all the responsibility to frameworks, libraries, and tools, a developer has a good chance of writing bad code. We always make mistakes, some more, some less, there is no silver bullet.

Try to understand one thing: beautiful code is not so important anymore in a world where a tool can generate a good piece of code.The tools that help us today to build assets can be used by tools to automatically create HTML/CSS/JS code from layouts produced in programs such as Sketch. See this plugin example that is no longer updated since 2015 and already tried to automate the code export in Sketch. The guy was trying to make HTML code from the layout drawn in Sketch version 3. Today the Sketch is currently in the version 42, and in version 43, Sketch is opening the code of its files in JSON format. Which brings us to the next subject.

Design Automation

*“We have a new file format which is more compact, and enables more powerful integrations for third-party developers. — *Sketch Team

Sketch will become a development platform. Opening the code of your files, anyone will be able to read these files and from there create anything. How long for someone to create a plugin that reads the Sketch file in JSON format and automatically generates HTML, CSS, and JS from a Sketch layout?

“Computers evolve. If the principles changed there would be no basis for evolution. — Caio Vaccaro

Okay, but wait: even before this new Sketch file format, there were already some tools you might not have known as Teleport, which turns any website into an Sketch artboard. Also, UIPad converts Sketch layout to HTML,CSS, and React! Take a look:

This trend was already drawn a long time ago. It’s the smart way to go. You can do more important things than sitting in front of the computer switching between browser, layout, browser, layout.

We have a design that integrates with the API, pulling real content on interface. We have a design tool that exports layout to HTML, CSS, andJS code ready to be used, but we’re still using code as it used. There is one more step that can be improved.

WebAssembly (Wasm)

Another important point, which has nothing defined yet, but which can start to make sense. All that story of WebAssembly, which is a new binary (bytecode, actually) format created by Google, Microsoft, Mozilla, and several others.

The code format of WebAssembly can be decoded much faster than JavaScript is parsed. This really brings to the Web the experience of native apps, specially on the mobile.

The cool thing is that other languages can be compiled for WebAssembly. Today the project is a little more focused on C / C++, but other languages will certainly be covered. The main goal of WebAssembly is performance.

One concern that comes up in the air is that it smells of monopoly. Remember Flash? Whether he wanted it or not it was an alternative to creating something native on the Web. But the grace is that:

WebAssembly does not replace JavaScript. Everything has backward compatibility, everything will run in the same universe as JS and security will have the same restrictions as JS;
It is not just a company or group that is behind Wasm, but several like Firefox, Chromium, Edge and Webkit;
To run WebAssembly you won’t need to run third-party plugins, since the browser engines will be fully compatible;

Do you understand why searching for a clean code (as we know it today) does not make that much sense anymore? Your website/product bytecode will be generated by a Sketch-like tool.

Conclusion

This article is opinionated and full of guesses from my own. All of these can become true, or not. IMHO, sooner or later the front-end profession as we know will no longer exist.

I don’t know if this will really happen, but until yesterday automated cars and trucks were just movie stuff.

Forem: Diego Eis

Good practices for JAMStack projects

Use CDN

All the code live in GIT

Build tools

Automated Builds

Atomic Deploys

Cache invalidation

Conclusion

6 tips to succeed in freelancing and remote work

1. Give status

2. Never omit information

3. Keep the project repository always up-to-date

4. Bad news is better than no news

5. Freelancer: don't get a project if you think you will not finish it in time

6. Be responsible

The (probable) end of the front-end profession as you know it

Working with real data direct from Design

Beautiful code is not important

Design Automation

WebAssembly (Wasm)

Conclusion

Further reading

Actual data in design

About not using fake text in layouts

WebAssembly

About the Front-end Tools Scenario