Let's create a completely type-safe web application in a Clean Architecture using a couple of modern libraries. Such systems are orders of magnitude more reliable than the untyped counterparts. Plus, they are easier to understand, maintain and refactor. Tech: TypeScript, GraphQL, MongoDB, React.
One of the most substantial productivity boosts I've experienced recently is the decision to avoid using the mouse as much as possible on my MacBook. It made me faster at getting stuff done, and also more focused on the task I'm working on. Try it, and your hands will be grateful too: using a mouse is not just slow, but also a significant cause of RSI.
When it comes to front-end, my weapon of choice right now is the React, TypeScript and Parcel trinity. It's an easy, robust and productive setup, with minimal configuration. This guide will show you how to create a matching debugger experience in VS Code.
Let's look at how to connect our debugger to a React app generated with Create React App. We'll see how to launch a browser from VS Code to inspect a remote, async API call. It's super-powerful and at the same time a surprisingly easy thing to do. So, no more excuses when it comes to debugging you CRA and React apps.
Some of the more powerful debug features we will need going forward are only available with a dedicated configuration file. We'll look at creating a launch.json and the built-in VSCode debug console. This post is the last piece of the puzzle before we can move on to debug complex, real-life applications.
It's possible to replay code blocks in the debugger to see how they behave in different scenarios. Let's look at how to change variables and restart functions in the call stack - a huge time saver!
It's important to learn how to navigate around the code you're inspecting. Going through each line of the codebase would be tedious and unnecessary. Debuggers offer handy ways of looking into what matters and jump out of code blocks that don't. Let's see how to step into, over and out of functions while debugging!
Readable code is something of myth amongst developers. We'd all love clear programs, but big problems seem to generate challenging code. I think there is a solution and it's easier than you might think.
I think it is a mistake to solve possible, future difficulties. Not catering for potential features today has the advantage of keeping the codebase more flexible. If you do not commit to a solution now, you'll have more wiggle room tomorrow. Keep your options open.
The typical problems associated with software projects, cost overruns and delays are all closely related to the disregard for simplicity.
Everyone's very busy, but the results are weak. The product is buggy and unreliable; the codebase is messy; people are frustrated. Sounds familiar? Let's talk about focus and attention.
Code is written for computers to run. But there is an equally important audience - people reading, changing and maintaining the codebase in the future
Let's be honest. Few care about the intricacies of programming outside the developer community. What people crave, though, are solutions, regardless of the implementation details.
The recommendations are based on real-life experience, enabling teams to consistently deliver high-quality products, be more productive and less frustrated. Topics range from architecture to code formatting.