Five backend books you should read in 2021.

Powering up your backend knowledge? Our friends at Packt have shared five backend books you should read in 2021.

Node Cookbook, Fourth Edition

Discover solutions, techniques, and best practices for server-side web development with Node.js 14

What reviews say:

“Want to learn Node.js, brush up on your skills, or discover the latest features of Node 14 and beyond? This book is for you! Written by a senior developer and Red Hatter, With a thorough presentation of everything Node, Bethany Griggs delivers from cover to cover in this latest Node Cookbook edition.

Node.js Web Development, Fifth Edition

Server-side web development made easy with Node 14 using practical examples

What reviews say:

“This book is great. I had some knowledge about full-stack JavaScript, but this book has already taught me a lot. I wouldn’t say that this book is for a complete beginner to software development (coding), but it’s definitely good if you need to deepen your understanding of JavaScript, or if you’re interested in getting started with JavaScript from another backend language like Python, C#, Ruby, etc.”

ASP.NET Core 5 and React

Full-stack web development using .NET 5, React 17, and TypeScript 4

What reviews say:

“The book had a very methodical approach to building single-page applications through React. I am familiar with React and .NET separately and partly why I could pick up the concepts in the book faster but I believe otherwise too, things are laid out very clearly. Recommend it for beginners.”

Full-Stack React, TypeScript, and Node

Build cloud-ready web applications using React 17 with Hooks and GraphQL

What reviews say:

“Nook has a philosophy of “learning by doing” “

Building Vue.js Applications with GraphQL

Develop a complete full-stack chat app from scratch using Vue.js, Quasar Framework, and AWS Amplify

What reviews say:

“This book is a fantastic deep dive into building an end-to-end application on AWS. I really like the fact that he dove deep into many topic areas, showing how to tie everything together to build something that is a real-world use case. The information in this book can also be used in many other areas so the knowledge is very transferable to other scenarios and use cases.”

What titles do you recommend? Share your thoughts in the comments.  Looking for more inspiration? Here are more book recommendations.


Using Bash in Windows – today

using bash in windows today

“… However, when we talked with web developers, they still struggled with using Windows as their primary devbox.”

The above quote is from Kevin Gallo, the VP of Windows Dev platform, and was delivered around mark 0:38 of his presentation in Microsoft’s Build 2016 keynote. He then continued with the observation that “… many of them have workflows which rely on open source command line tools, scripts and frameworks”, and finished with a slide that his audience was – at first – slightly unsure on how excited to get about: Bash is coming to Windows.

Screenshot #1: Kevin Gallo’s slide from Build 2016 announcing Bash coming to Windows
Screenshot #1: Kevin Gallo’s slide from Build 2016 announcing Bash coming to Windows

If you let the video play for another 7 seconds, you’ll also catch a glimpse of Gallo’s audience. You can see the emotions depicted on their faces form a picture that explains perfectly the complex (and sometimes tumultuous) relationship of Microsoft with Linux and the Open Source world. Three persons are smiling excitedly and beginning to slow clap (the ones that suddenly realise how much easier managing their OS stack or scripting their Windows environment will become). You then have the classic cautious indifference of the majority of developers that wait to see whether this is “worth getting excited about”. Finally, you can also detect some unguarded annoyance from the fanboy crowd (“Seriously? I have to sit and hear about Bash? What’s wrong with PowerShell?”).

Personally, I belong to the first group. Despite working with open source technologies since the beginning of my professional career back in 2003, I’ve never managed to move away from Windows. To this effect, when I saw Rich Turner and Russ Alexander casually doing a apt-get install git on Windows to install git, I was excited. A lot.

But until the functionality showcased in the video above is mature and stable enough to be rolled out, I’ll continue using my current workflow which has served me faithfully since 2011: And that is bash on Windows (To be precise: A more “cut down” version of Bash. Read on for details).

The challenge: Production-strength command line workflow in Windows.

One might argue that Windows was never meant to be “driven” from the command line.

Microsoft tried to mitigate this back in 2006 by rolling out PowerShell, a shell and scripting language that gives users full access to their whole Windows environment. For Windows devs this was a great extra tool but for all other developers it was still not enough to lure them away from the power and versatility they found on the Linux command line.

Add to this the strongly opinionated naming conventions and approaches that PowerShell inherited from the .NET Framework (did you know that cd is but an alias to the “proper” command which is Get-ChildItem? That’s camelcase _and_ a dash that autocompletes with tab even if you type it in lowercase. Strange stuff) and you can see why it’s really hard for e.g. a PHP developer to consider it for his dev workflow.

When every single blogpost or article or tutorial written about a subject, e.g. “how to rebase branches in git”, includes instructions and screenshots that clearly demonstrate the flow in a Linux shell, it’s only natural for the developer to assume that this is the correct way of doing things.

Towards a solution: Install Git for Windows

For my frontend-with-a-bit-of-PHP-but-from-a-Windows-OS workflow I always relied on certain “battle proven” tools. WinSCP was the weapon of choice when files needed to be moved from one place to another (either via FTP, SFTP, SCP or even rSync). Putty allowed me to connect via SSH to all my dev boxes. TortoiseGIt ensured that I could use git directly from my Windows explorer interface.

The first “lightbulb / aha” moment for me occurred when I installed Git for Windows after being prompted to “try it out on the command line” by a colleague.
One of the steps of the install wizard prompts you to choose “How would you like to use Git from the command line?”:

Screenshot #2: Choosing how to use Git for Windows
Screenshot #2: Choosing how to use Git for Windows

… and it mentioned “Bash”!

Installation completes and suddenly I get a shell in Windows that looks suspiciously similar to what I’m used to in Linux or iOS installations:

Screenshot #3: MinTTY terminal emulator window
Screenshot #3: MinTTY terminal emulator window

Bash in Windows: How it works

Kudos? To the awesome devs that worked to bring Git to windows –
In essence the installer sets up a unix-like shell environment (MinGW – “Minimalist GNU for Windows”) which – very roughly speaking – creates the needed Unix layer that shells like Bash can run onto.
A terminal emulator called MinTTY is also installed (shown in screenshot #3 above) which is a Windows program that runs the Bash shell which in turn enables you to use quite a good subset of the Linux commands needed for an open source dev workflow.

Looks are important

… especially if you are an ex-designer-turned-frontend-developer. Going from the black and white severity of cmd.exe (where you could not even resize the window to the dimensions you wanted) to MinTTY definitely boosted my “developer happiness” feeling:

Screenshot #4: MinTTY terminal emulator window
Screenshot #4: MinTTY terminal emulator window

In the above example, I manually mapped the colours from the famous Solarized colour theme to the default 16 ANSI colours. For the font I chose the crystal clear Consolas font set at 12 point, although I’ve recently been experimenting with Adobe’s Source Code Pro as an alternative.

The MinTTY window can be resized to any dimension of your choosing. You can also use the same shortcuts as you use in the browser to resize the text on the fly (CTRL+plus, CTRL+minus or CTRL+mouse wheel). Finally you can launch as many instances of MinTTY as you want, enabling you to lay out a series of windows into your codebase and file structure, exactly as it suits you:

Bash in Windows Screenshot #5: Multiple instances running at the same time at different dimensions and font-size
Screenshot #5: Multiple instances running at the same time at different dimensions and font-size

I can now do {{thing}} from the command line

The list below demonstrates just a small subset of the stuff you can do with Bash in Windows that I found particularly useful and / or helpful.

  • Git
    No more “download and unzip”. Git clone any repo of your choosing in any directory in your filesystem. The handy “GIT Bash here…” shortcut that appears when you right click any folder is particularly useful here.
  • Linux command line
    MinGW supports a subset of the various commands and programs available in Linux, things like awk, sed, grep, find are all here, ready to be used. Shortcuts are also available (CTRL+U, CTRL+K for inline editing, CTRL+R to lookup on Bash history etc) as well as piping and redirection.
  • SSH
    OpenSSH works right out of the box. Set up your keys by using ssh-keygen (exactly the same way you would do in a Linux box) and then connect to any of your machines. You can also setup an ssh-agent (exactly the way Beanstalk or Github or Bitbucket explain in their online tutorials) to ensure you don’t retype your password all the time. Of course ftp and scp are available as well.
  • Vim
    No more notepad++ for me. After I went through the steep-as-mount-Everest learning curve I found out that vim was the best tool for quick text edits (I’ve strongly resisted the urge to play with emacs. We’ll see).
  • Bash scripting
    The very first bash script I experimented with (and use constantly nowadays) is z: I no longer rely on lengthy cd statements such as:
    cd /some_directory/nesting/nested/my_work
    But rather do a:
    z my_work
    … and I’m immediately taken to the directory I want.

“You should really switch to {{enter Linux distro name here}}”

Indeed. But even if I do so, there is still a vast number of devs out there who still need / have to work with Windows. One year ago, Isaac Schlueter (co-founder and CEO of the Node Package Manager – NPM) had this to say:

Bash in Windows: this matters
If you want devs using your code, this matters

Until WSL is out … Bash in Windows

The soon-to-be-released Windows Subsystem for Linux is a brilliant (and much-needed) step forward in making the Windows environment a first-class citizen for open source development workflows.Nevertheless, there is no need to wait for Microsoft to make WSL available to everyone.

I’ve been using Bash in Windows – in my daily workflow – for the last 5 years and it’s working like a charm.
If you want to do the same, simply install Git for Windows.