Media is too big
VIEW IN TELEGRAM
Workflow for generating viral Shorts/Tiktoks.
1. Prompt builder. Google Sheets. Control Panel.
π₯ - I want to see the continuation and the result of the work
1. Prompt builder. Google Sheets. Control Panel.
π₯ - I want to see the continuation and the result of the work
π₯78β€9π2π€1
Is it difficult to implement what I showed above?
I can teach you how to do the same in just a few posts here.
π₯ - I want this
I can teach you how to do the same in just a few posts here.
π₯ - I want this
π₯115
Good. I see your interest. π
Let's do this. 100 fires π₯ on this post, and I'll run a free mini-course right here on Telegram on how to write Shorts Monster
Let's do this. 100 fires π₯ on this post, and I'll run a free mini-course right here on Telegram on how to write Shorts Monster
π₯138
Let's get started.
We can base our Shorts bot on the Shorts creation technology described by 10x income in this video.
Where should we start when implementing such a task? With decomposing the task into smaller steps.
In our case, the initial decomposition might look like this:
1. Writing the script
2. Dividing the script into scenes
3. Writing prompts to generate images for each scene
4. Generating AI images
5. Downloading video footage from stock
6. Generating voiceovers
7. Generating the video
In the future, these steps could become separate modes of the bot. In the end, we will also create a unified mode that will combine the entire pipeline.
Next, we need to determine what classes will be present in our bot.
We can base our Shorts bot on the Shorts creation technology described by 10x income in this video.
Where should we start when implementing such a task? With decomposing the task into smaller steps.
In our case, the initial decomposition might look like this:
1. Writing the script
2. Dividing the script into scenes
3. Writing prompts to generate images for each scene
4. Generating AI images
5. Downloading video footage from stock
6. Generating voiceovers
7. Generating the video
In the future, these steps could become separate modes of the bot. In the end, we will also create a unified mode that will combine the entire pipeline.
Next, we need to determine what classes will be present in our bot.
π₯51π3
Next, we need to define the classes of our bot. Here are a couple of simple rules to help with that.
For this, we need to:
1. Identify the actors
2. Consider the Single Responsibility Principle (SRP)
An actor is an entity that interacts with the system or performs certain actions within the system. For example, Writer, Downloader, Generator, etc.
Letβs take our task decomposition and match each point to the corresponding actor.
1. Writing the script - ScriptWriter
2. Dividing the script into scenes - ScriptDivider
3. Writing prompts to generate images for each scene - PromptsWriter
4. Generating AI images - ImageGenerator
5. Downloading video footage from stock - FootageDownloader
6. Generating voiceovers - VoiceGenerator
7. Generating the video - VideoGenerator
In the next post, we will analyze our potential classes in terms of SRP.
For this, we need to:
1. Identify the actors
2. Consider the Single Responsibility Principle (SRP)
An actor is an entity that interacts with the system or performs certain actions within the system. For example, Writer, Downloader, Generator, etc.
Letβs take our task decomposition and match each point to the corresponding actor.
1. Writing the script - ScriptWriter
2. Dividing the script into scenes - ScriptDivider
3. Writing prompts to generate images for each scene - PromptsWriter
4. Generating AI images - ImageGenerator
5. Downloading video footage from stock - FootageDownloader
6. Generating voiceovers - VoiceGenerator
7. Generating the video - VideoGenerator
In the next post, we will analyze our potential classes in terms of SRP.
π₯27β€βπ₯5π1
SRP. The first principle of SOLID.
This principle states that a class should perform a specific task and should not be overloaded with other unrelated tasks.
Just as a function should execute only one complete task, this principle applies to classes as well.
However, unlike functions, itβs harder to define the boundary of violating this principle with classes.
So, use common sense and avoid extremes:
1. Donβt create classes that do too much (the God Object anti-pattern).
2. But also, creating a multitude of classes with just one method inside may also not be the best practice.
...
This principle states that a class should perform a specific task and should not be overloaded with other unrelated tasks.
Just as a function should execute only one complete task, this principle applies to classes as well.
However, unlike functions, itβs harder to define the boundary of violating this principle with classes.
So, use common sense and avoid extremes:
1. Donβt create classes that do too much (the God Object anti-pattern).
2. But also, creating a multitude of classes with just one method inside may also not be the best practice.
...
π₯27β€1π1
So, letβs take another look at our potential classes and consider their responsibilities.
1. Writing the script - ScriptWriter
2. Dividing the script into scenes - ScriptDivider
3. Writing prompts to generate images for each scene - PromptsWriter
4. Generating AI images - ImageGenerator
5. Downloading video footage from stock - FootageDownloader
6. Generating voiceovers - VoiceGenerator
7. Generating the video - VideoGenerator
We can definitely say that each of the classes β ScriptDivider, ImageGenerator, FootageDownloader, VoiceGenerator, and VideoGenerator β has its own distinct responsibility. Each class performs its specific task, aligning with the SRP principle.
What about the ScriptWriter and PromptsWriter classes? At first glance, it might seem that their responsibilities overlap (writing text), and we could combine these two classes into a single Writer class without violating SRP.
In reality, these classes deal with different aspects of text, and their roles do not overlap. Each has its own distinct task. Therefore, itβs correct to keep these classes separate, which will align with the SRP principle.
Thus, our list of classes looks like this:
1. ScriptWriter
2. ScriptDivider
3. PromptsWriter
4. ImageGenerator
5. FootageDownloader
6. VoiceGenerator
7. VideoGenerator
1. Writing the script - ScriptWriter
2. Dividing the script into scenes - ScriptDivider
3. Writing prompts to generate images for each scene - PromptsWriter
4. Generating AI images - ImageGenerator
5. Downloading video footage from stock - FootageDownloader
6. Generating voiceovers - VoiceGenerator
7. Generating the video - VideoGenerator
We can definitely say that each of the classes β ScriptDivider, ImageGenerator, FootageDownloader, VoiceGenerator, and VideoGenerator β has its own distinct responsibility. Each class performs its specific task, aligning with the SRP principle.
What about the ScriptWriter and PromptsWriter classes? At first glance, it might seem that their responsibilities overlap (writing text), and we could combine these two classes into a single Writer class without violating SRP.
In reality, these classes deal with different aspects of text, and their roles do not overlap. Each has its own distinct task. Therefore, itβs correct to keep these classes separate, which will align with the SRP principle.
Thus, our list of classes looks like this:
1. ScriptWriter
2. ScriptDivider
3. PromptsWriter
4. ImageGenerator
5. FootageDownloader
6. VoiceGenerator
7. VideoGenerator
β€βπ₯34β€3π3π₯°3
After our classes are defined, itβs time to:
1. Create the botβs basis
2. Plan the folder and file structure of the project
100 fires π₯ on this post, and weβll continue.
1. Create the botβs basis
2. Plan the folder and file structure of the project
100 fires π₯ on this post, and weβll continue.
π₯109
Since the process and results of the work of each of our classes depend on the project folder, we see that all our classes have a common element β the project working directory.
In addition to this, different classes may have other common functionality, such as reading or writing data to CSV files or a database.
To avoid code duplication (the DRY principle) and to facilitate project maintenance, let's use inheritance to extract the common elements of our child classes into a separate parent class (base class).
Thus, we introduce an additional class, which we will call BaseGenerator.
We will inherit our classes from this base class, allowing us to access its attributes and methods from the child classes.
Therefore, our inheritance hierarchy looks like this.
In addition to this, different classes may have other common functionality, such as reading or writing data to CSV files or a database.
To avoid code duplication (the DRY principle) and to facilitate project maintenance, let's use inheritance to extract the common elements of our child classes into a separate parent class (base class).
Thus, we introduce an additional class, which we will call BaseGenerator.
We will inherit our classes from this base class, allowing us to access its attributes and methods from the child classes.
Therefore, our inheritance hierarchy looks like this.
β€βπ₯38β€1
β¬οΈ This architecture will be sufficient for our project.
We could also build the architecture using interfaces, abstract classes, and contracts, but I don't want to overcomplicate things or overload you with information right now.
I can explain this separately in the future, but for now, this will be enough.
We could also build the architecture using interfaces, abstract classes, and contracts, but I don't want to overcomplicate things or overload you with information right now.
I can explain this separately in the future, but for now, this will be enough.
β€24π8π₯4
Where will we store our classes? We'll create a package called modules, and inside it, weβll create a .py file for each class.
Additionally, weβll create a main.py file in the root of the project. This file will serve as the entry point to the application and will contain the logic for launching the different modes of the bot.
Weβll also need a data folder in the bot, where various global project files can be stored, such as the keyfile.json file for integrating the bot with Google Sheets.
Thus, our project structure will look like this.
We created a similar bot structure in lesson 4 of the Pinterest Money course. In that lesson, youβll also learn how to build a prompt builder, and connect the bot to Google Sheets.
Additionally, weβll create a main.py file in the root of the project. This file will serve as the entry point to the application and will contain the logic for launching the different modes of the bot.
Weβll also need a data folder in the bot, where various global project files can be stored, such as the keyfile.json file for integrating the bot with Google Sheets.
Thus, our project structure will look like this.
We created a similar bot structure in lesson 4 of the Pinterest Money course. In that lesson, youβll also learn how to build a prompt builder, and connect the bot to Google Sheets.
β€βπ₯21π₯9π2β€1
Take note of the module structure above.
For each class corresponding to a separate task, we have created a separate .py file (module).
Donβt think that only one class can be created in a single .py file.
You can also create additional classes in the same file if they are closely related to the task of the main class.
So, the recommendation is:
One file β one task.
This makes the code easier to read and maintain.
For each class corresponding to a separate task, we have created a separate .py file (module).
Donβt think that only one class can be created in a single .py file.
You can also create additional classes in the same file if they are closely related to the task of the main class.
So, the recommendation is:
One file β one task.
This makes the code easier to read and maintain.
π₯23π1
At this stage, we have created the structure of our bot and the class hierarchy.
The next step is to create the skeleton of our classes and the bot's launch logic.
The next step is to create the skeleton of our classes and the bot's launch logic.
β€βπ₯22π1
Let's start with the base class. In the file base_generator.py, we'll declare the BaseGenerator class and then create the class constructor (the init method).
Earlier, we determined that a common element among our child classes will be the project working folder.
Therefore, in the constructor of the base class, we need to accept a variable containing the project folder name (project_folder) as an argument.
Then, we'll create an instance attribute (self.project_folder) and assign it the path to the project folder, formed using the os module.
Additionally, it would be a good idea to create attributes for the paths to other project folders in the base class and ensure their automatic creation (self.generated_images, self.generated_video).
In this class, we will also create methods for reading and writing CSV files, which will be needed for our child classes.
An example implementation of this class might look like this (image).
Earlier, we determined that a common element among our child classes will be the project working folder.
Therefore, in the constructor of the base class, we need to accept a variable containing the project folder name (project_folder) as an argument.
Then, we'll create an instance attribute (self.project_folder) and assign it the path to the project folder, formed using the os module.
Additionally, it would be a good idea to create attributes for the paths to other project folders in the base class and ensure their automatic creation (self.generated_images, self.generated_video).
In this class, we will also create methods for reading and writing CSV files, which will be needed for our child classes.
An example implementation of this class might look like this (image).
β€22π5