Starting the year, I asked myself what a perfect workflow environment for a designer and front-end developer in a new laptop should look like for me. The first answer was very obvious; just buy a MacBook. It makes sense given the fact that, in a single operational system, I would have access to both design & development tools in the same machine, without the hassles of having to switch between different computers or OS's every time I went from one part of the work to the other.
The catch here is that I was (and still am to be quite honest) on a tight budget. I knew that a new machine had to be a laptop for portability, but here in Brazil, hardware can be quite expensive. The idea of building a Hackintosh, a MacOS installed in hardware that is not provided by Apple (we shall not discuss the ethical shenanigans behind this here) was a considerable option to me, but the new hassles of having to deal with several hardware compatibility issues quickly threw me away of that as well.
I was left with the dual-boot option. Windows 10 for all my design needs with the Adobe suite, and a Linux distro for all the development tasks. "Well, that is not going to be very practical" I assumed at the time. But after some time of tweaking and testing with this setup, I've come to a very pleasant result, and wanted to share some of the details of how I got that to work and integrated it on my workflow, in case some other person in a similar position wants to replicate this setup for some reason.
I've had my fare share of Linux distro experiences, going through vanilla Ubuntu, Xubuntu, Fedora, Manjaro, Arch, Deepin, and lastly Kubuntu. So from the very start I knew I would want a KDE based distro for some very picky reasons that you really don't want to be bothered with. In the end of the day, distro choices narrow down to personal preference, so I chose Kubuntu for this one.
The very first thing I did on the machine was a fresh install of Windows, to get rid of all manufacturer bottlenecks. With that done, I make sure to run some well-known debloater scripts for Windows 10. I'm pretty sure some of then are not working after the 1909 update, but every little bit of telemetry and background service that I can disable on Windows is already a relief to the machine's resources. You can find the debloater scripts here: https://github.com/Sycnex/Windows10Debloater
Note that the script creator advises against running those scripts on certain instances of a Windows install. In any case, always create a restore point before you run any of these scripts.
After that is time for the Linux install. How you set it up, and how much space in your disk you're gonna give to each OS is entirely up to you. A guide to dual-booting install for absolute beginners is in the link bellow for Ubuntu. The majority of other distributions will very probably follow the same footsteps, so no mystery here: https://itsfoss.com/install-ubuntu-1404-dual-boot-mode-windows-8-81-uefi/
This narrows down to installing Adobe programs, synchronizing everything needed, and setting up a Google Drive folder where all my files are going to be. More specifically, I make sure to configure all the interfaces in Adobe programs the way I personally like, and install additional resources like plugins, brush sets and that sort of thing.
Now that a Linux distribution of my choice is installed, I can start preparing the development environment. Here is a checklist of everything we will be installing and configuring:
- Chrome - The number one browser in the world statistically speaking, so even if it's not your preference as a default browser, it's important to have Chrome in your system, especially as a front-end developer, since Chrome Development Tools are the best in the market for web debugging.
- Firefox - Second alternative for web browser, and comes pre-installed with most Linux distributions. It also comes with very powerful development tools, but I prefer Chrome. May be useful to keep it around for testing.
- Visual Studio Code - It is my go to editor, and notably one of the most advanced and versatile among IDE's. There are many good text editors out there for you to choose: Sublime, Atom, Brackets. I use Visual Studio Code out of personal preference. Just keep in mind that I'll be recommending extensions for VS Code that may not be available in other IDE's.
For now, I still find no use on getting a custom shell like myZSH, but I use Tilix as my terminal software. It comes with a handy screen divider that makes my workflow with terminal applications a bit easier then having to switch tabs.
- Git - Must have tool for version control. I use GitHub for all projects both personal and public. A very simple guide on setting up Git and synchronizing it with your GitHub account can be found in the Odin Project page. https://www.theodinproject.com/courses/web-development-101/lessons/setting-up-git
- Node.js and npm - Many modules and some compiling tools that I use depend on NPM, so it's good practice to have it installed globally, or just import the modules you need inside your project directory for a more organized workflow. You can find the Node.js installer for your platform on their official website here: https://nodejs.org/en/download/ The NPM documentation can be found here: https://docs.npmjs.com/
Tree - Sometimes I need a tree vision of my project structure and "tree" does exactly that. You can find it in the Ubuntu mirror
sudo apt install tree.
Of course you can find many more useful Terminal Tools for more complex workflows, but these seem to be the essential ones for the kind of initial setup that I plan on going with here.
Starting with the browser, Chrome, that has some pretty neat extensions to help in the testing and debugging process. The ones I currently use on a regular basis:
- Window Resizer - Resizes the browser resolution to emulate different screen resolutions. Useful for testing responsive layouts and creating resolution presets.
- Page Ruler - Gives you the ability to draw a ruler in the browser screen and view the width, height and top, bottom, left and right position. Very useful when you're still designing the web page and want to have and idea how your specs are going to behave on the browser.
- CSSViewer - A simple extension that shows you all CSS properties applied to a selected element. It is completely possible to do that in the Developer Tools, but the process is simpler and faster with this extension.
Now for the fun part: customizing the IDE. For the theme I use the Halycon theme with FireCode as the main font. Visual Studio Code has a lot of very useful extensions that you should absolutely use to bring ease to your workflow. Here is the list of the ones I use most frequently:
- Bracket Pair Colorizer - Matching Brackets are now identified with colors.
- HTML CSS Support - Adds missing native CSS support for HTML documents.
- HTML Snippets - Adds snippets support to HTML Markdown.
- Indent-Rainbow - Makes indentation easier to visualize with a color strap that colorizes the indentation in front of the text.
- IntelliSense for CSS class names - Auto-completion for CSS classes defined in the HTML document.
- Path IntelliSense - Auto-completion for paths in project directories.
- Prettier - Code formatter that parses it and reprints it with defined rulesets for consistent code.
- Sass - Adds full support to .scss and .sass files.
- Git History - Its basically git log inside your VS Code.
There are two particular cases where I don't use the extensions available in VS Code; the Live Server and the Sass Compiler. I set them up in the terminal. The reason for this is because the Node.js module browser-sync has live-reload and scroll-sync built in across all devices connected to your local network. On the other side, the node-sass module is very flexible to setup, and it's the perfect kind of flexible to transform a complex Sass file structure into a single .css minified style-sheet. In case you don't know what exactly is Sass, it is a pre-processor for CSS that adds some enhancements like variables, nested rules, mixins and functions. Think about it as giving your CSS superpowers. I'll only go over the live server settings since not everybody uses Sass.
If you have Node.js and npm installed (you can check with
npm -v in the terminal), you can install it with the command:
npm install -g browser-sync
-g ensures that the module is installed globally, which is more interesting then having to repeat this setup in every individual project.
Now we need to create an alias for the command, since it's pretty extensive and you probably don't want to type it every time you open a project. To create that alias, we need to locate the shell configuration file that handles aliases. In Linux, this is a hidden file located on your home directory. You can find it on the terminal by listing all files with
ls -a, and looking for the file
If you never used an alias before, this file will probably be empty. Enter the following lines on it and save it.
export LOCAL_IP="ipconfig getifaddr en0"
alias serve="browser-sync start -s -f . --no-notify --host $LOCAL_IP --port 9000"
What it does is create a variable, called LOCAL_IP, that stores your current IP adress regardless of the network you're connected. The next line creates an alias called "serve" that will be used as a substitute for the entire command. I call the alias "serve", but you can customize it the way you want. And if you know what you're doing and want to customize the browser-sync even further, you can check out their documentation here: https://browsersync.io/docs/command-line
The whole point of putting together a system like this was making sure I have all the tools I need to work in any part of the design or development process. So, assuming I get to work on both of them in the same project (what is usually the case in personal projects for example), how exactly does it all come together? This is how I usually aproach my projects:
The first step is figuring out how the UX is going to work by researching and understanding what the end-user experience should be like for a specific project.
The second step is building the sitemap, which will give me an idea of how the navigation on the website is going to work as whole.
The next step is the wireframing and layout. That's when we go in the individual pages and try to figure out their layouts in a rudimentary first sketch that will give us an idea of the website's flow as a whole.
The last stage is the visual design itself, where elements are fine-tuned to a user-ready prototype with complete design specs that can be used to ease the development stage.
After that, the design is ready to be exported. In Adobe XD, that is done via the Share section, where you can export your project in a variety of formats for presentation, and also as a document with specs.
Switching to Linux, the only thing left to do is open the project in the browser, and it will be avaible to me with all the project specs.
Also remember the way files work in both systems if you're thinking about doing file transfers internally. Windows uses a NTFS file system, while Linux usually uses ext4. This means Linux can acess your Windows partition and all the files inside, but Windows does not work in vice-versa. This problem is mitigated if you're using a cloud solution like Google Drive.
And this is it for this setup. Let me know what you think and feel free to drop your sugestions on this process.
Make better choices about your code and your career.