The Raidenvideoripper release in Microsoft Store – applications for quick installation of video and conversion to MP4, WebM, GIF formats.
https://apps.microsoft.com/detail/9nvzjs98smgc?hl=en-us&gl=GE&ocid=pdpshare
Soft & Games
The Raidenvideoripper release in Microsoft Store – applications for quick installation of video and conversion to MP4, WebM, GIF formats.
https://apps.microsoft.com/detail/9nvzjs98smgc?hl=en-us&gl=GE&ocid=pdpshare
New version of Raidenvideoripper – 1.0.2.0
Added support for a dark theme for Windows 11.
Raiden Video Ripper is an application for simple video cutting in Webm, GIF formats.
Please visit the Release page to keep abreast of the latest issues and updates:
https://github.com/demensdeum/RaidenVideoRipper/releases
Today, neural networks are used everywhere. Programmers use them to generate code, explain other solutions, automate routine tasks, and even create entire applications from scratch. It would seem that this should lead to an increase in efficiency, reducing errors and acceleration of development. But reality is much more prosaic: many still do not succeed. The neural networks do not solve key problems – they only illuminate the depth of ignorance.
The main reason is that many developers are completely relying on LLM, ignoring the need for a deep understanding of the tools with which they work. Instead of studying documentation – a chat request. Instead of analyzing the reasons for the error – copying the decision. Instead of architectural solutions – the generation of components according to the description. All this can work at a superficial level, but as soon as a non -standard task arises, integration with a real project or the need for fine tuning is required, everything is crumbling.
The neural networks generate the code generalized. They do not take into account the specifics of your platform, version of libraries, environmental restrictions or architectural solutions of the project. What is generated often looks plausible, but has nothing to do with the real, supported code. Even simple recommendations may not work if they belong to the outdated version of the framework or use approaches that have long been recognized as ineffective or unsafe. Models do not understand the context – they rely on statistics. This means that errors and antipattterns, popular in open code, will be reproduced again and again.
The code generated AI is often redundant. It includes unnecessary dependencies, duplicates logic, adds abstractions unnecessarily. It turns out an ineffective, heavy structure that is difficult to support. This is especially acute in mobile development, where the size of the gang, response time and energy consumption are critical.
The neural network does not conduct profiling, does not take into account the restrictions of the CPU and GPU, does not care about the leaks of memory. It does not analyze how effective the code is in practice. Optimization is still handmade, requiring analysis and examination. Without it, the application becomes slow, unstable and resource -intensive, even if they look “right” from the point of view of structure.
Do not forget about safety. There are already known cases when projects partially or fully created using LLM were successfully hacked. The reasons are typical: the use of unsafe functions, lack of verification of input data, errors in the logic of authorization, leakage through external dependencies. The neural network can generate a vulnerable code simply because it was found in open repositories. Without the participation of security specialists and a full -fledged revision, such errors easily become input points for attacks.
Pareto law works clearly with neural networks: 80% of the result is achieved due to 20% of effort. The model can generate a large amount of code, create the basis of the project, spread the structure, arrange types, connect modules. However, all this can be outdated, incompatible with current versions of libraries or frameworks, and require significant manual revision. Automation here works rather as a draft that needs to be checked, processed and adapted to specific realities of the project.
Nevertheless, the future looks encouraging. Constant updating of training datasets, integration with current documentation, automated architecture checks, compliance with design and security patterns – all this can radically change the rules of the game. Perhaps in a few years we can really write the code faster, safer and more efficiently, relying on LLM as a real technical co -author. But for now – alas – a lot has to be checked, rewritten and modified manually.
Neural networks are a powerful tool. But in order for him to work for you, and not against you, you need a base, critical thinking and willingness to take control at any time.
Summing up Demensdeum Challenge 1.
Our winner is an option from SNKBP95 manually written on assembler – the size of the executable file 50kb along with the picture.
Congratulations to the winner!
https://github.com/snkbp95/DemensDeum-Coding-Challenge-1/
I present to your attention fork Kate text editor called Gingerita. Why Fork, why, what is the goal? I want to add the functionality that I need in my work, so as not to wait for the correction, adding features from the Kate team, or the adoption of my corrections to the Main branch.
At the moment, a prototype version for Windows is currently available, almost vanilla version of Kate with minimal changes. For Gingerita, I have developed two plugs – an image of the images directly from the editor and the built -in browser, for debugging my web projects or for interacting with AI with assistants such as ChatGPT.
The version for Windows can be tested by the link below:
https://github.com/demensdeum/Gingerita/releases/tag/prototype
Welcome to the support page!
If you have questions, problems with Demensdeum products or you want to offer improvements, we are always ready to help.
How to contact us:
support@demensdeum.com
We try to answer appeals within 3-5 business days.
What to indicate in the letter:
The name of the product
Version (if known)
A detailed description of the problem
Screenshots or videos (if possible)
Device and operating system on which the problem arose
We thank you for the use of our products and strive to make your experience as convenient and pleasant as possible.
Sincerely,
Demensdeum team
With the development of large language models (LLM), such as ChatGPT, more and more developers use them to generate code, design architecture and accelerate integration. However, with practical application, it becomes noticeable: the classical principles of architecture – Solid, Dry, Clean – get along poorly with the peculiarities of the LLM codgendation.
This does not mean that the principles are outdated – on the contrary, they work perfectly with manual development. But with LLM the approach has to be adapted.
Why llm cannot cope with architectural principles
Incapsulation requires understanding the boundaries between parts of the system, knowledge about the intentions of the developer, as well as follow strict access restrictions. LLM often simplifies the structure, make fields public for no reason or duplicate the implementation. This makes the code more vulnerable to errors and violates the architectural boundaries.
Design patterns, such as an abstract factory or strategy, require a holistic view of the system and understanding its dynamics. Models can create an interface without a clear purpose without ensuring its implementation, or violate the connection between layers. The result is an excess or non -functional architecture.
LLM do not seek to minimize the repeating code – on the contrary, it is easier for them to duplicate blocks than to make general logic. Although they can offer refactoring on request, by default models tend to generate “self -sufficient” fragments, even if it leads to redundancy.
Clean implies a strict hierarchy, independence from frameworks, directed dependence and minimal connectedness between layers. The generation of such a structure requires a global understanding of the system – and LLM work at the level of probability of words, not architectural integrity. Therefore, the code is mixed, with violation of the directions of dependence and a simplified division into levels.
Wet instead of Dry
The WET (Write EVERYTHING TWICE) approach is more practical in working with LLM. Duplication of code does not require context from the model of retention, which means that the result is predictable and is easier to correctly correct. It also reduces the likelihood of non -obvious connections and bugs.
In addition, duplication helps to compensate for the short memory of the model: if a certain fragment of logic is found in several places, LLM is more likely to take it into account with further generation. This simplifies accompaniment and increases resistance to “forgetting”.
Avoiding complex encapsulation and relying on the direct transmission of data between the parts of the code, you can greatly simplify both generation and debugging. This is especially true with a quick iterative development or creation of MVP.
A simple, flat structure of the project with a minimum amount of dependencies and abstractions gives a more stable result during generation. The model adapts such a code easier and less often violates the expected connections between the components.
Most language models are trained on outdated versions of documentation. Therefore, when generating instructions for installing SDK, errors often appear: outdated commands, irrelevant parameters or links to inaccessible resources. Practice shows: it is best to use official documentation and manual tuning, leaving LLM an auxiliary role – for example, generating a template code or adaptation of configurations.
It is important to understand that the difficulties from Solid, Dry and Clean concern the codhegeneration through LLM. When the developer writes the code manually, these principles continue to demonstrate their value: they reduce connectedness, simplify support, increase the readability and flexibility of the project.
This is due to the fact that human thinking is prone to generalization. We are looking for patterns, we bring repeating logic into individual entities, create patterns. Probably, this behavior has evolutionary roots: reducing the amount of information saves cognitive resources.
LLM act differently: they do not experience loads from the volume of data and do not strive for savings. On the contrary, it is easier for them to work with duplicate, fragmented information than to build and maintain complex abstractions. That is why it is easier for them to cope with the code without encapsulation, with repeating structures and minimal architectural severity.
Large language models are a useful tool in development, especially in the early stages or when creating an auxiliary code. But it is important to adapt the approach to them: to simplify the architecture, limit abstraction, avoid complex dependencies and not rely on them when configuring SDK.
The principles of Solid, Dry and Clean are still relevant-but they give the best effect in the hands of a person. When working with LLM, it is reasonable to use a simplified, practical style that allows you to get a reliable and understandable code that is easy to finalize manually. And where LLM forgets – duplication of code helps him to remember.
I want to share my new project-the NFT collection “Demens TV Heads”.
This is a series of digital art work, they reflect people of different characters and professions, in the style of the Demensdeum logo.
The first work is Fierce “Grozny” this is a stylized self -portrait.
I plan to release only 12 NFT, one each every month.
Each work exists not only in the Ethereum blockchain, but is also available on the Demensdeum website and in the Github-Roads, along with metadan.
If interested, see or just evaluate visually, I will be glad:
https://opensea.io/collection/demens-tv-heads
https://github.com/demensdeum/demens-tv-heads-collection
https://demensdeum.com/collections/demens-tv-heads/fierce.png
https://demensdeum.com/collections/demens-tv-heads/fierce-metadata.txt