This guide will cover the fundamentals of Git. You will learn why version control is necessary and how version control systems work. This information will help you to master practical work with Git successfully.
Software development is a challenging process that tends to become much more complex as the number of participants increases. More people in the team create more communication and require more synchronization (sharing knowledge of system parts and processes, keeping track of the business and its requirements). The cost of error increases, and the system can no longer fit in just one head, while a change on one side triggers other changes.
There are no programs without errors. Their number can be reduced with the great help of a type system, linters, tests, or even a whole department of testers, but it’s impossible to remove them completely. This is the reality we must face; the best thing we can do is learning how to track these errors and fix them as soon as possible.
Linux or Mac users sometimes need to run Windows-only programs, and, in turn, Windows users, especially programmers, may need to launch Linux or another version of Windows. The classic example is Photoshop or games.
Have you ever wondered how the browser understands which page to open when you enter the site address in the URL bar? This is a much deeper issue than you might think. It needs to be solved in a way that isn't based on moving between sites, but on how computers are connected with each other.
Docker is a program that allows the operating system to run processes in an isolated environment based on specially created images. And, while the technologies underlying Docker existed earlier, it was Docker that changed the way we now build project infrastructure, assemble and launch services.
Deployment is the process of web service “deployment”, e.g. of a website, in the operating environment. An operating environment is a place where a website is started and available for requests. This can be ready-made hosting as well as your own server infrastructure.
Programmers like compact code. If it's done correctly, then it should be easy to read and shouldn't contain any parts that make you think about it more than necessary.
Is it worth using libraries for a few simple functions? Wouldn't writing them yourself be easier? These are questions regularly asked by novice developers and by almost anyone working on Hexlet projects. Let's take a closer look.
You can write any code inside files (and outside of definitions) in scripting languages like JavaScript. This can be defining and calling functions, or declaring and changing variables. This freedom simplifies development by allowing you to create one-time scripts for simple or infrequent tasks. On the other hand, careless development leads to flaws that make the code and maintaining it significantly more difficult. They're so common in production code that we need to address them separately.
In dynamic languages, code files can be either executable scripts or modules. Each of these kinds of files have their own limitations; they're arranged differently, and they behave differently depending on their role.
Creating functions is easy, creating functions properly is harder. Poorly designed functions frequently have to be rewritten, it's difficult to adapt them to new requirements, and they don't get tested properly. In this article, we'll look at key methods for sharing responsibilities, building chains of functions, and designing function signatures. The article's content is based on common mistakes made by Hexlet students in their projects.
According to our students, projects are one of Hexlet's strongest features. These are special tasks that closely mimic real-world tasks, and they're done on your own computer, outside of Hexlet tasks.
This article outlines how projects work, how long they take to complete, and why poorly written code doesn't work, and it also contains thoughts from our students about our projects.
There are two approaches to writing code: top-down and bottom-up (descending and ascending). With the top-down approach, high-level logic is implemented first, followed by the details. With the bottom-up approach, everything is reversed; the details come first, followed by the general logic.
These approaches are frequently contrasted in books. It's generally considered that if you choose one approach, then you have to exclude the other one. However, this is not the case. In the article, I'll tell you why only going down one path can cause problems.
In this article, I'll look at bad function design decisions that don't seem too bad at first glance. Optional parameters in JavaScript, flag handling, violation interfaces, and the misuse of the rest operator.
In some languages, such as Python and JavaScript, variables and constants declared at module level can be imported to other parts of the program. On the one hand, this opens up a world of possibilities when compared to languages that require all data to be contained within functions, classes, etc. On the other hand, it makes it much easier to write code with issues.
