Demens Deum

(and how not to be a guru whose advice ceases to work after the update)

“Apps may only use public apis and must run on the currently shipping os.” Apple App Review Guidelines

If you have ever started working with a new framework and caught yourself thinking: “Now I’ll understand everything, documentation is for bores”-you are definitely not alone. Many developers have a natural instinct: first try, and only then – read. This is fine.

But it is at this stage that you can easily turn off the right path and find yourself in a situation where the code works … But only today, and only “I have.”

Why is it easy to “figure it out” – is it not enough?

Freimvorki, especially closed and proprietary, are complex and multi -layered. They have a lot of hidden logic, optimization and implementation features, which:

* not documented;
* not guaranteed;
* can change at any time;
* are a commercial secret and can be protected by patents
* contain bugs, flaws that are known only to the developers of the framework.

When you act “on a hunch”, you can easily build architecture in random observations, instead of support on the clearly described rules. This leads to the fact that the code becomes vulnerable to updates and EDGE cases.

Documentation is not a restriction, but support

The developers of frameworks create manuals for a reason – this is an agreement between you and them. While you are acting as part of the documentation, they promise:

* stability;
* support;
* predictable behavior.

If you go beyond this framework – everything that happens next becomes exclusively your responsibility.

Experiments? Certainly. But in the framework of the rules.
Curiosity is the developer’s super -via. Explore, try non -standard, test boundaries – all this is necessary. But there is an important “but”:

You need to experiment in the framework of the documentation and Best Practices.

Documentation is not a prison, but a card. She shows what opportunities are really planned and supported. It is such experiments that are not only useful, but also safe.

Caution: Guru

Sometimes you may encounter real “experts”:

* They conduct courses
* perform at conferences,
* write books and blogs,
* shared “their approach” to the framework.

But even if they sound convincing, it is important to remember:
If their approaches are contrary to documentation, they are unstable.

Such “empirical patterns” can:

* work only on a specific version of the framework;
* be vulnerable to updates;
* Break in unpredictable situations.

Guru is cool when they respect the manuals. Otherwise, their tips must be filtered through official documentation.

A little Solid

Three ideas from Solid principles are especially relevant here:

* Open/Closed Principle: Expand the behavior through a public API, do not go into the insides.
* Liskov Substition Principle: Do not rely on implementation, rely on the contract. Disorders – everything will break when replacing the implementation.
* Dependency Inversion: high -level modules should not depend on low -level modules. Both types should depend on abstractions. Abstraction should not depend on the details. Details should depend on abstractions.

What does this mean in practice? If you use a framework and directly tied to its internal details – you violate this principle.
Instead, you need to build dependence on public interfaces, protocols and contracts that the framework officially supports. This gives:

* the best isolation of your code from changes in the framework;
* the ability to easily test and replace dependencies;
* predictable behavior and stability of architecture.

When your code depends on the details, and not on abstractions, you literally embed yourself in a specific implementation that can disappear or change at any time.

And if the bug?

Sometimes it happens that you did everything right, but it works incorrectly. This happens – frameworks are not perfect. In this case:

* Gather a minimum reproduced example.
* Make sure you use only documented API.
* Send a bug-port-they will definitely understand you and, most likely, will help.

If the example is built on hacks or bypasses, the developers are not required to support it, and most likely your case will simply miss.

How to squeeze the maximum from the framework

* Read the documentation. Seriously.
* Follow the guides and recommendations from the authors.
* Experiment – but within the described.
* Check the tips (even the most famous speakers!) Through the manual.
* Fold bugs with minimal cases and respect for the contract.

Conclusion

Freimvorki are not black boxes, but tools that have the rules of use. To ignore them means writing the code “at random”. But we want our code to live for a long time, delight users, and does not break from the minor update.

So: trust, but check. And yes, read the manuals. They are your superpower.

Sources

https://developer.apple.com/app-store/review/guidelines/
https://en.wikipedia.org/wiki/SOLID
https://en.wikipedia.org/wiki/API
https://en.wikipedia.org/wiki/RTFM

Docker has become an indispensable tool in modern Devops and development. It allows you to isolate the encirclement, simplify the outfit and quickly scale applications. However, by default, Docker requires a ROOT, and this creates a potentially dangerous zone, which is often ignored in the early stages.

Why does Docker work from Root?

Docker uses the capabilities of the Linux: Cgroups, Namespaces, Iptables, Mount, Networking and other system functions. These operations are available only to the super -user.

That’s why:
* Dockerd demon starts from Root,
* Docker commands are transmitted to this demon.

This simplifies the work and gives full control over the system, but at the same time it opens up potential vulnerabilities.

Why is it dangerous: Container Breakout, CVE, RCE

Container Breakout

With weak insulation, an attacker can use Chroot or Pivot_root to enter the host.

Examples of real attacks:

* CVE-2019-5736-vulnerability to RUNC, allowed to rewrite the application and execute the code on the host.
* CVE-2021-3156-vulnerability to SUDO, allowed to get a ROOT inside the container and get out.

RCE (Remote Code Execution)

If the application in the container is vulnerable and starts from Root, RCE = full control over the host.

Rootless Docker: Solution of the problem

To minimize these risks, Rootless mode appeared in Docker. In this mode, both the demon and the containers are launched on behalf of the usual user, without any Root-privilegies. This means that even if an attacker receives control over the container, he will not be able to harm the host system.
There are restrictions: you can not use ports below 1024 (for example, 80 and 443), the –privileged mode, as well as some network modes, is not available. However, in most development scenarios and CI/CD Rootless Docker, it copes with its task and significantly increases the level of security.

Historically, launch from Root – Antipattern

From the very beginning, the principle of the smallest privileges has been applied in the Unix/Linux world. The fewer rights the process, the less harm it can do. Docker initially demanded a Root access, but today it is considered a potential threat.

Sources

https://docs.docker.com/engine/security/rootless/
https://rootlesscontaine.rs/

The non-obvious problem of Docker containers: hidden vulnerabilities

What is “Dependensky Hell” (DH)?

“Dependency Hell” (DH) is a term denoting a problem that arises when managing dependencies in the software. Its main reasons are in the conflict of versions, the difficulties of integrating various libraries and the need to maintain compatibility between them. DH includes the following aspects:

– Conflicts of versions: projects often require specific versions of libraries, and different components can depend on incompatible versions of the same library.
– Difficulties in updates: Dependencies updating can lead to unexpected errors or compatibility breakdown, even if a new version contains corrections or improvements.
– the surroundings: the desire to isolate and stabilize the environment led to the use of virtual environments, containerization and other solutions aimed at simplifying dependence management.

It is important to note that although the elimination of vulnerabilities is one of the reasons for the release of updated versions of the libraries, it is not the main driving force of DH. The main problem is that each change – whether it is correcting bugs, adding a new functionality or eliminating vulnerability – can cause a chain of dependencies that complicate the stable development and support of the application.

How did the fight against DH led to the creation of Docker?

In an attempt to solve the problems DH, the developers were looking for ways to create isolated and stable surroundings for applications. Docker was a response to this challenge. Containerization allows:

– isolate the environment: all dependencies and libraries are packaged along with the application, which guarantees stable work anywhere where Docker is installed.
– Simplify the deployment: the developer can once configure the environment and use it to deploy on any servers without additional settings.
– minimize conflicts: since each application works in its own container, the risk of conflicts between the dependencies of various projects is significantly reduced.

Thus, Docker proposed an effective solution to combat the DH problem, allowing developers to focus on the logic of the application, and not on the difficulties of setting up the environment.

The problem of outdated dependencies in doCker

Despite all the advantages of Docker, a new direction of problems has appeared – the obsolescence of addictions. This happens for several reasons:

1. The container freezes in time

When creating a Docker image, a certain state of all packages and libraries is fixed. Even if after assembly in the basic image (for example, `ubuntu: 04.20,` python: 3.9`, `node: 18-alpine`), vulnerabilities are found or new versions are produced, the container continues to work with the initially installed versions. If the image is not to be sent, the application can work with obsolete and potentially vulnerable components for years.

2. Lack of automatic updates

Unlike traditional servers, where you can configure automatic packages update through system managers (for example, `Apt Upgrade` or` NPM Update`), containers are not updated automatically. The update occurs only when re -electing the image, which requires discipline and regular control.

3. Fixed dependencies

To ensure stability, the developers often fix the version of dependencies in files like `redirements.txt` or` package.json`. This approach prevents unexpected changes, but at the same time freezes the state of dependencies, even if errors or vulnerability are subsequently detected in them.

4. Using obsolete basic images

The basic images selected for containers can also be outdated over time. For example, if the application is built on the image of `node: 16`, and the developers have already switched to` node: 18 ‘due to improvements and corrections, your environment will remain with an outdated version, even if everything works correctly inside the code.

How to avoid problems with outdated dependencies?

Include regular inspections for outdated dependencies and vulnerabilities in the CI/CD process:

– For Python:

pip list --outdated

– for node.js:

npm outdated

– Use tools to analyze vulnerabilities, for example, `trivy`:

trivy image my-app

Monitor the updates of the basic images

Subscribe to the updates of the basic images in Docker Hub or the corresponding repositories on GitHub in order to timely learn about critical corrections and updates.

Conclusion

The problem of dependency Hell arose not only because of the need to eliminate vulnerability, but also as a result of difficulties in managing and updating dependencies. Docker has proposed an effective solution to combat DH, providing isolated and stable surroundings for applications. However, with the advent of containerization, a new task arose – the need for regular renewal of images in order to prevent the obsolescence of dependencies and the appearance of critical vulnerability.

It is important for modern DevOPS specialists not only to solve the problems of conflicts of versions, but also to introduce regularly and automated control practices for the relevance of addictions so that the containers remain safe and effective.

Introduction

The last article examined the general case of using the Builder pattern, but the option was not touched upon when the object is created in stages in time.
Builder pattern (builder) is a generating design template that allows you to gradually create complex objects. It is especially useful when the object has many parameters or various configurations. One of the interesting examples of its use is the ability to separate the process of creating an object in time.
Sometimes the object cannot be created immediately – its parameters can become known at different stages of the program.

An example on Python

In this example, the object of the car is created in stages: first, part of the data is loaded from the server, then the user enters the missing information.

import requests

def fetch_car_data():
    response = requests.get("https://api.example.com/car-info")
    return response.json()

builder = CarBuilder()

# Backend API data
car_data = fetch_car_data()
builder.set_model(car_data["model"])
builder.set_year(car_data["year"])

# User input
color = input("Car color: ")
builder.set_color(color)

gps_option = input("GPS feature? (yes/no): ").lower() == "yes"
builder.set_gps(gps_option)

car = builder.build()
print(car)

Imagine an API call, data entry occur in different parts of the application, or even in different libraries. Then the use of the Builder pattern becomes more obvious than in a simple example above.

Advantages

– the output is an immune structure that does not need to store optional data for temporary assembly
– The object is collected gradually
– avoiding complex designers
– The assembly code of the object is incomplinge only in one essence of Builder
– Convenience of understanding code

Sources

https://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional-ebook/dp/B000SEIBB8
https://demensdeum.com/blog/2019/09/23/builder-pattern/

Start Demensdeum Coding Challenge #1
Prize 100 USDT
1. We need to write Render pictures for Windows 11 64 bit
2. Render
https://demensdeum.com/logo/demens1.png
3. The picture should be integrated into the application
4. Graphic API – Direct3D or DirectDRAW
5. Wins that whose application turned out to be the smallest in size in bytes
6. The image should be 1 in 1 posely as original, save colors
7. Any languages/frameworks do not require additional installation -> so that you can start immediately from the application. For example, if the solution is only one Python script, then such a solution is not suitable. The installation of Python, Pygame and manually launch are required. Good example: Python Script wrapped together with Python and Pygame in EXE, which starts without additional installations.
8. Give in the form of a link to a public repository with the source code, instructions for assembling the application. Good example: a project with the assembly instructions at Visual Studio Community Edition

Deadline: June 1 Summing up the contest

Reference solution on ZIG + SDL3 + SDL3_Image:
https://github.com/demensdeum/DemensDeum-Coding-Challenge-1

When I thought about creating my own blog in 2015, I faced the question: which platform to choose? After much searching and comparison, I settled on WordPress. This was not a random choice, but the result of analyzing the platform’s capabilities, its advantages and disadvantages. Today, I would like to share my thoughts and experience using WordPress.

Advantages of WordPress

• Ease of use
  One of the main reasons why I chose WordPress is its intuitive interface. Even if you have never worked with a CMS before, you can master WordPress in a matter of days.
• A huge number of plugins
  WordPress provides access to thousands of free and paid plugins. These extensions allow you to add almost any functionality related to blogging, from SEO optimization to social media integration.
• Scalability
  WordPress is great for blogs of all sizes. Having started with a simple personal blog, I know I can easily grow it by adding new features and functionality.
• Wide selection of topics
  There are a huge number of free and paid themes available on WordPress that will allow you to create a pretty good looking blog in a short time. Creating a custom design will require the sensitive hand of a designer.
• SEO-friendly
  WordPress is designed to be search engine friendly by default. Plugins like Yoast SEO make it easy to optimize your content to improve its search rankings.
• Community and Support
  WordPress has one of the largest communities in the world. If you have a problem, you’ll almost certainly find a solution on forums or blogs dedicated to the platform.
• Multilingual support
  Thanks to plugins like WPGlobus, I can blog in multiple languages, which is especially important when working with an audience from different countries.

Disadvantages of WordPress

• Vulnerability to attacks
  WordPress’ popularity makes it a target for hackers. Without proper protection, your site can become a victim of attacks. However, regular updates and installing security plugins help minimize the risks.
• Plugin Dependency
  Sometimes the functionality you want to add requires installing multiple plugins. This can slow down your blog and cause conflicts between extensions.
• Performance Issues
  On large blogs, WordPress can start to slow down, especially if many plugins are used. To solve this problem, you need to optimize the database, implement caching, and use a more powerful hosting.
• Cost of some functions
  While the basic version of WordPress is free, many professional themes and plugins cost money. Sometimes you have to invest to get all the features.

Conclusion

WordPress is a tool that provides the perfect balance between simplicity and power. For me, its advantages outweigh the disadvantages, especially considering the large number of solutions to overcome them. Thanks to WordPress, I was able to create a blog that perfectly suits my needs.