
Hello! In that lecture, I will explain the general idea of my new course.
Hello! In that lecture, I will explain the requirements that you should follow to understand what I will talk about in that course.
Requirements:
Programming language
OOP(object-oriented programming) *
Frontend, backend, communications, API, logging *
Requirements with * are optional but highly advised!
Hello! In that lecture, I will tell you why there is no one direct solution for anything. I will try to give you my explanations and show you how you can solve problems in your code. But for every project, there are different outcomes. There are different solutions.
Hello! In that lecture, I will tell you about the "we need ... today" problem. You may have heard a lot of sayings like that, but what is the real issue? Watch the lecture to understand.
Hello! In that lecture, I will show you the boilerplate code with the problem inside of it. It is a simple LoadController with a write() function, but is it that simple?
In that lecture, we will go three months later and see what happens to our code.
In that lecture, we will rewrite and refactor our code so its implementation is not as bad as before. Point out that the thing I wrote in that lecture is not perfect, and the solution depends on your application.
In that lecture, I will sum up the "today" problem. So, I think that you understand that "today" can happen once, twice, but cannot exist constantly. That is the main problem - constant "today".
Hello, everyone! Today I will explain the avoidance of legacy code. How can we do that? Is it even possible? Let's find out.
Now, let's try to write something today. It is obviously bad but there are moments where we need to code rapidly. But, how to do it without messing up our project? Let's find out.
Welcome back! That section will tell you about different layers in IT. But, first of all, let's talk about why they are essential.
Now, it's time to show you the code that contains everything in one layer. Can you find where the problem is?
The problem may be obvious - everything is contained inside of one layer. But how can we solve it? Watch the lecture to find out.
The first layer that we are going to talk about is the presentation layer. It is one of the most known layers in programming, and it is used in every application. But, what presentation layer actually is? Let's find out
The second layer is the business logic layer. That is the heart of your code and your application logic.
The last layer that I'm going to talk about is the data layer. It's the database that you use and all the tools that connect it to your application.
Now, let's connect all of these layers together. How they should work with each other in different applications? Let's find out
You already know about all of the layers that are common in the IT world. But are there any other layers? If so, what are their advantages?
Now, let's get to the real-world examples of presentation layers in our programs. We will have a simple application with login functionality that works through the terminal.
We already have a simple presentation layer. The next thing that we need is a business logic layer. Let's write and connect it to our UI.
Now, let's create a data layer. It will be a simple file with passwords and usernames, but how can we connect it to our application?
Finally, we created and connected all of the layers. They work together, and we can fix the bugs and finish our application.
Different layers for our application are amazing practices. However, when we are talking about their advantages, we should also mention their disadvantages.
Now, let's talk about the information that comes out of our application and goes directly to the end-user. But, first of all, the case is "Can you quickly add a field?"
That is an example of the application where we send the raw responses to the user. Why is it so bad? Let's find out.
That lecture will extend the possible problems with the bad response management system. There is no only "one field" but maybe tonnes of code that you will need to append to your application.
The easiest solution to our problem is one class that will contain all of the response formattings that we need. Let's write that class together
Our solution works like a charm, but still, there can be some problems with it. I will tell you about them in that lecture.
Logging is one of the most valuable parts of any application. But why do a lot of people omit it in their programs?
Now, let's look at the application where we will need to add logging. You may already guess that it will take a lot of time, and our work will not be amusing in any way.
Once again, we face a problem that can be solved with one class. In that case, it is LoggingFormatter - the one place to write and format all of the logs for our application
LoggingFormatter works perfectly fine. Still, there is an issue - we need to create and configure it every time we write logs. But, what if we do that once? But where can we do that? The answer is simple - in ResponseMixin
Now our logs work like a charm. We know about the problems, we look at the issues of our program. But, still, there is something to talk about - visualization, gathering, formatting, and other things that happen after the code.
One of the most hated things is tests. The majority of the programmers don't like them, but they need them. Let's start with a simple case that will show you the real need in tests.
Now, let's look at the simple application with a hidden bug. It shows that the abundance of tests is fatal, so we will also write some tests for that application.
Tonnes of people keep telling everyone that tests are not worth it. They don't generate income, and that's true. However, they can save your money.
You already know about the importance of tests, but I want to tell you the difference between test types. Since that course is for the programmers, we will talk about unit tests, functional tests, and smoke tests.
Now I will show you the most basic structure for the tests that I write. It will be different for your language and project, but still, there are some things you can get from the code I will show you.
The last thing that I want to say about tests is why we need to test everything
Settings are the root of every project. They are needed everywhere, but what may be the problem with them?
In that lecture, you will see a simple code with three files that each contain settings for different environments. What is the problem with those files?
We will merge all of the different settings files into one. But, what if there are specific configurations for the various environments? We will also talk about that.
That video sums up the settings in different files and why I think having one file is still more efficient.
There will be no code in that section since it is all about the money. Let's compare two companies that have different views on technical debt, and we will see who wins.
There will be no code in that section since it is all about the money. Let's compare two companies that have different views on technical debt, and we will see who wins.
Our company needs money, but we don't want to have technical debt. How should we solve that riddle? Actually, we can leverage that debt, but how to do that? Let's find out.
The previous video was about a small or average team. But, if you are working in a big production, then there is another way of managing technical debt.
However, I want to add that it is really complicated to work in a big team, and often you will spend more time on simpler problems. But, that is about management.
That is the last video that sums up the whole course. Thank you!
Hello, everyone! My name is Andrey, and I have been working with Python for over five years. During that time, I faced lots of errors, mistakes, and problems with my code. I tried to make everything quicker but did not understand anything after a short period. Have you ever had a problem understanding the structure, complexity, and code you are managing? Every time you change your code, you find tonnes of dependencies and cannot make clean and beautiful code. That course will help you to manage your applications and write cleaner code. I provided real-life examples in the lessons with the "Case" prefix. These cases may occur in any company, environment, or project. Also, there is a "Code" prefix, where I write code showing you common mistakes and solutions. I use Python as the language for that course, but you can choose any and follow along. These principles give you ideas on how to write software, not just Python code. The lectures with the "Code" prefix are the ones where I will code. I used them to illustrate the real issues in the code and give my solutions for them. If you need to write clean, working, and reliable code - that course is for you.