Gingerita Prototype Windows

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

Support for Demensdeum products

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

Vibe-core tricks: why LLM still does not work with Solid, Dry and Clean

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

encapsulation

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.

Abstracts and interfaces

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.

Dry (Donolt Repeat Yourself)

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 Architecture

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.

What works better when working with LLM

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”.

Simple structures instead of encapsulation

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.

Simplified architecture

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.

SDK integration – manually reliable

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.

Why are the principles still work – but with manual development

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.

Conclusion

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.

Demens TV Heads Nft

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

Super programmer

Who is he – this mysterious, ephemeral, almost mythical super programmer? A person whose code is compiled the first time is launched from half -pike and immediately goes into the Prod. The legend transmitted in bytes from senor to jun. The one who writes bugs specifically so that others are not bored. Let’s honestly, with warmth and irony, we will figure out what superpowers he must have to wear this digital cloak.

1. Writes on C/C ++ without a unified vulnerability
Buffer Overflow? NEVER HeARD of it.
The super programmer in C ++ has no inconvenientized variables – they themselves are initialized from respect. He writes New Char [256], and the compiler silently adds a check of borders. Where others put a breakpoint – he glance. And the bug disappears.

2. Writes Fichs without bugs and testing
He does not need tests. His code tests himself at night when he sleeps (although … does he sleep?). Any line is a final stable version, immediately with the support of 12 languages ​​and the NASA Accessible level. And if the bug still came across, then the Universe is testing him.

3. It works faster than AI
While Chatgpt is printing “What a good question!”, The super programmer has already locked the new OS, ported it to the toaster and documented everything in Markdown with diagrams. He does not ask Stackoverflow – he supports him with his questions from the future. GPT is studying on his communities.

4. He understands someone else’s code better than the author
“Of course, I wrote it … But I do not understand how it works.” – An ordinary author.
“Oh, this is due to the recursive call in line 894, which is tied to the side effect in the REGEX filter. Smart.” – Super programmer without blinking.
He reads Perl on the first attempt, understands the abbreviations in the names of variables, and bugs captures by vibration of the cursor.

5. Writes the cross -platform code on the assembler
Why write on Rust, if possible on pure X86, ARM and RISC-V right away, with a flag “works everywhere”? He has his own table of the Oppodes. Even CPU thinks before spoiling his instructions. He does not optimize – he transcends.

6. He answers questions about the deadlines up to a second
“When will it be ready?”
“After 2 hours, 17 minutes and 8 seconds. And yes, this is taking into account the bugs, a smoke break and one philosophical question in the chat.”
If someone asks to do faster-he simply rebuilds the space-time through Make -jives.

7. Reversees and repairing proprietary frameworks
Proprietary SDK fell off, API without documentation, everything is encrypted by Base92 and coughs Segfault’s? For a super -programmer, this is an ordinary Tuesday. He will open a binary, inhale HEX, and an hour later there will be a patch with a fix, improvements of performance and added Dark Mode.

8. Designer and UX specialist for himself
UI comes out for him that people cry with beauty, and the buttons are guessed by intuition. Even cats cope – verified. He does not draw an interface – he opens his inner essence, like a sculptor in marble. Each press is delighted.

9. Conducts marketing research between commits
Between Git Push and Coffee Break, he manages to collect market analytics, build a sales funnel and rethink the monetization strategy. On weekends tests hypotheses. He has A/B tests are launched automatically when he opens a laptop.

10. repeats Microsoft alone
That for corporations 10 years and a thousand engineers, for him – Friday evening and good pizza. Windows 11? Did Windows 12. Office? Already there. Excel? He works on voice management and helps to plan a vacation. Everything works better and weighs less.

11. unfolds and supports infrastructure for 1 million users
His homemade NAS is a Kubernetes Clister. Monitoring? Grafana with memes. It unfolds the API faster than some manage to open Postman. He has everything documented, automated and reliably like a Soviet teapot.

12. Technical support is not required
Users do not complain about it. They just use it with reverence. FAQ? Not needed. Tutorials? Intuition will tell. He is the only developer who has the “Help” button to the gratitude page.

13. He does not sleep, does not eat, is not distracted
He feeds on caffeine and a pure desire to write a code. Instead of sleep, refactoring. Instead of eating – Debian Packages. His life cycle is a continuous development cycle. CI/CD is not Pipeline, this is a lifestyle.

14. communicates with customers without pain
“We need to make Uber, but only better, in two days.” – “Look: here is Roadmap, here are the risks, here is the MVP. And let us first decide on the goals.”
He knows how to say no “so that the customer replies:” Thank you, now I understand what I want. ”

15. instantly programs nuclear reactors
How much heat is released when the uranium nucleus is split? The super -programmer knows. And he knows how to steal it in Rust, C, Swift, even in Excel. Its reactor is not only safe – it is also updated by OTA.

16. has knowledge in all possible areas
Philosophy, physics, tax reporting of Mongolia – everything in his head. He participates in quizzes, where he is a leader. If he doesn’t know something, he simply temporarily turned off the memory to make room for new knowledge. Now it will return.

17. Knows all algorithms and design patterns
No need to explain to him how A*, Dijkstra or Singleton works. He came up with them. With him, the patterns behave correctly. Even antipattterns are corrected themselves – from shame.

18. worked in Apple, Google and left boredom
He was everywhere: Apple, Google, NASA, IKEA (tested the cabinet interface). Then I realized that it was already too good, and went to develop free open-source projects for pleasure. He does not need money because:

19. He has Pontid Bitcoin and he is Satoshi Nakamoto
Yes, it’s him. Just does not say. All wallets with millions of BTC are actually on his flash drive, walled up in concrete. In the meantime, he writes Backend for a farmer cooperative in the outback, because “it was interesting to try Kotlin Multiplatform.”

Conclusion: A little seriousness
In fact, programmers are ordinary people.
We are mistaken. We get tired. Sometimes we are so confident in ourselves that we do not see the obvious – and it is then that the most expensive mistakes in the history of it are made.

Therefore, it is worth remembering:

* It is impossible to know everything – but it is important to know where to look.
* Working in a team is not a weakness, but a path to a better decision.
* The tools that protect us are not “crutches”, but armor.
* Ask is normal. To doubt is right. To make mistakes is inevitable. Learning is necessary.
* Irony is our shield. The code is our weapon. Responsibility is our compass.

And legends about a super -programmer are a reminder that we all sometimes strive for the impossible. And this is precisely in this – real programming magic.

Why documentation is your best friend

(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

Cube Art Project 2

Meet – Cube Art Project 2

The second version of the station editor, fully rewritten on pure JavaScript without Webassembly.
Light, fast and starts right in the browser – nothing more.

This is an experiment: cubes, color, freedom and a little meditative 3D geometry.
You can change colors using RGB-sloders, save and load scenes, move around space and just play.

Control:
– WASD – moving the camera
– Mouse – rotation
– Gui – color settings

Online:
https://demensdeum.com/software/cube-art-project-2/

Sources on Github:
https://github.com/demensdeum/cube-art-project-2

The project is written on pure JavaScript using Three.js.
Without frameworks, without collectors, without Webassembly – only Webgl, shaders and a little love for pixel geometry.

The scenes can be saved and loaded – create your worlds, save as JSON, share or return later to refinement.