PromptQL + Golang service = ❤️
Читать полностью…
Local LLM + llama.cpp = ❤️
Читать полностью…
https://homepages.uc.edu/~thomam/Articles/HowSoftwareCompaniesDie.pdf
Читать полностью…
What are soft-skills?
You may have soft-skills. But if you say that you have soft-skills, you certainly don't have soft-skills.
Being lazy sometimes is good. It forces you to value your energy more to do only reasonable things when doing unreasonable things cost you a damage.
Читать полностью…
jzx777/making-bots-with-promptql-functions-in-prompts-d1be8cea6409" rel="nofollow">https://medium.com/@jzx777/making-bots-with-promptql-functions-in-prompts-d1be8cea6409
#PromptQL #llm #LocalLLM #Llama #golang #go #programming #opensource #library #programminglanguage #promptengineering #prompts
#cottagesoftware #craftprogramming #indieweb
#medium #article #blog
Стиль кода
Читал пост KOSки, думал. Исходник в посте напомнил о том, что думал про указатели на функции Роб Пайк.
И тут мысль пришла в голову. Люди шутят про Один-эсс и потом также шутя вопрошают как можно писать на том языке программирования, который использует для описания слова из твоего натурального mother tongue.
А вот так: Как авторы книги The elements of the programming style, которые ссылались на книжку о стиле в натуральном языке.
Формальные языки основанные на иных натуральных языках нежели анлийский это интересно, потому что может привнести что-то новое по форме. Язык это не просто, а совы не то чем кажутся
How can people management be performed in asynchronous remote work?
The idea of asynchronous remote work may sound wild for those who still believe in infinite acceleration of human work tempo. As micromanagement in the async work is not possible. But do we actually need it? If some work is so simple such that only an execution time or resource consumption matters, then this work should be automated with external tools or devices. This is what happened in case of development of higher level languages like C++, Pascal etc. which encapsulated common and trusted Assembly programming templates, for example. But Assembly programming work haven't become an energy drain machine (otherwise this work would just collapse and so development and maintenance of low-level systems). So current case with high level programming is not even close to this as there are a lot of work to be done in order to master higher level tools.
However, people management still needs a control on their employees to have a transparent feedback with users of product. But which if micromanagement is bad for complex work? From my experience of asynchronous work: just define meaningful schedule borders which are adequate to complexity of task. This is only possible with dialogue and trust for experienced software engineers, who are responsible for handling a project. Meaningful time spans from minimum of one day. In this case it is not matter at which hour a task is completed. It is a matter that it is known that task is eventually completed and validated. For example, if I have a task for "2 days" and I have a leisure time one day at midday, then I just continue working on this task at evening. Or I can do it at midday instead. It depends on my inner "clock". So it's clear how to solve the management problem with async work scenario.
There is another problem though: synchronization with team members on common work. However, if synchronization is needed too often then it's a problem which is similar to micromanagement. My favorite style of handling synchronization is just allocating a certain part of day for gathering requirements until exhaustion for a scope of feature(s). This also solves a problem of losing productivity on frequent context switches (which hurts more in case of "programming - human communication" than between different programming areas).
So both problems are solvable in simple ways. But social aspect is still left. As asynchronous work is still not a common trend now, a guy who works in this fashion, poses a competition pressure on those who can't work this way, but need to satisfy their "greater image". To this situation I can answer only with this: if you work good in way X, then it's good for you and you have other satisfying things. Otherwise you just need to switch to some peaceful strength-intensive activity.
"Why should I take a harder path if easy path leads to the same return?"
Imagine that you're a child who wants to get a candy and doesn't know a value of diamonds. Which choice do you take?
1. Watch 30 min long science-pop video about diamonds on Youtube. And then get a candy.
2. Take a pickaxe and dig a mine. And then get a candy and diamond.
Recently I briefly mentioned a type of employee like "sonic sports player". So how is it different from classical software engineer?
I do my job most perfomantly when I focus on one side of engineering for hours but of meaningful time: code, architecture, task planning or gathering requirements. And when I can do my job async way. That's my strength. However sometimes I had to fit in this picture in past times but eventually I failed more and I was burned out. And this led me to another personal crisis and thinking about nature of behaviors more deeply.
This crisis, my core mental state and my self-perception drove me for search on scientific whitepapers about differences between core groups in such things as risk tolerance patterns and strength capacity. For risk tolerance patterns I found this article: https://pubmed.ncbi.nlm.nih.gov/31120931/ . So from this perspective I've assumed that there are two main groups of people:
1) Action-driven people ("masc"). They are driven by intraspecific competition and have an apriori need to look greater than their neighbors. So they have high needs in movement and competition with other people. This can be probably linked to high total risk tolerance and strength capacity.
2) Passion-driven people ("fem"). They are driven by external specific competition and have low desire for intraspecific competition. So they don't have a strong need in looking greater than their neighbors. But they want a stable and comfy life. If they lack it, they tend to get into hysteric anger. This is probably linked to low total risk tolerance and strength capacity, and that risk tolerance in evening periods is not significantly different from "masc" group.
Drawing from these points, I could assume that desires for exploration, combat and arts do not differ between those two phenotypes holistically. What is different is what drives them: "mostly action" or "mostly reaction". For masc type exploration is a behavior to be more competitive than neighbors. For fem type exploration is a behavior for escaping a hatch of outer aggression (high competitive or dense fields can be thought as it) or lacking a solid foundation for their well-being. The same applies for combat and arts.
So, I think, that these "fittiest" lines exist for both types:
1) For action-driven people a highly competitive environment with lots of uncertainities would fit best. This is normally associated with CEOs, sales management and other close-to-business people.
2) For passion-driven people longing and asynchronous work would fit best. This is normally associated with creative and engineering occupations like software engineer, DevOps, UX design etc. Immediate handling of requests for these people is normally needed only when incidents occur. Which should be minimized to maximal extent if business is long playing and future-proof.
As I wrote before, monotonic behaviors eventually drown a software engineer into burnout sink. So I see it as a good point for moving towards asynchronous remote work (besides outer obstacles like unstable internet connection etc.). It fits into picture of non-regular and complex challenges more suitable than old-fashioned taylorism machine with micromanagement practices (which is commonly spelled as "Agile framework"). These challenges sometimes require a pause for the same purpose as emptiness of several kHz is required between radio waves (otherwise it leads to signal interference and thus to dropping of signal/noise ratio). It makes a work-life balance more full-filled and prospecious as I've already felt.
Читать полностью…
If something is thrown to me and it has no clear reason, then it's a cargo cult object. And I can treat it like a lava rock thrown by small monkey. But not all these monkeys accept this. Some of them grug for even hotter rock thrown to me. This is what drives seek of reason.
Читать полностью…
Slow life does not mean that hustle is "bad". Slow life means that fast mode is not regular and mere an exception in natural hunger of discoveries. Unlike fast life which proposes constant hurry and oversimplification until complete burnout and personal destruction (no person = no progress = no well-being).
Читать полностью…
https://habr.com/ru/companies/ruvds/articles/731162/
> fire talents
> mask managerial failure with "AI revolution"
Language of rude power works for short time, for quick goals. In all the time it's just a growing ball of mud.
Читать полностью…
llama.cpp server + PromptQL = ❤️
Читать полностью…
https://habr.com/ru/companies/ruvds/articles/777420/
Читать полностью…
Recently I wrote another article on making bots by prompt engineering with PromptQL. I explained how expansion and execution of code embeddings brings full power to prompt templates. Here it is:
jzx777/making-bots-with-promptql-code-embeddings-5b21efd52c51" rel="nofollow">https://medium.com/@jzx777/making-bots-with-promptql-code-embeddings-5b21efd52c51
For purpose of examples, I ran bot with the Openhermes Mistral 2.5B model and the llama.cpp server.
Openhermes model:
https://huggingface.co/TheBloke/OpenHermes-2.5-Mistral-7B-GGUF
llama.cpp server:
https://github.com/ggerganov/llama.cpp/tree/master/examples/server
#PromptQL #promptengineering #prompts #ai
#golang #go #programming #opensource #library #programminglanguage
#llm #LocalLLM #openhermes #llamacpp
#cottagesoftware #craftprogramming #indietech
#blog #article #medium
Most of UI features I met in various apps and websites, are focused on making using some service in easier way. Features which does the opposite, seem also interesting for me. This type of features makes usage of some addictive function harder, so energy cost of using these features can be at least perceptionally equalized to cost of doing something hard but good. However, I saw this principle only for features which attribute to negative profit for sales (ex. "unsubscribe" button which usually seems like an ARG quest). And not for features which attribute to positive changes for user: for example, making reading chat groups hard to view so user could focus more on their hobbies etc. I know that implementing this scenario in transparent way for user attributes to negative profit for service's stakeholders through chain in trivial case. So making "antiaddictive" features which benefit both for user and business to maximum degree, is a tricky task. But it's interesting because it makes managing software in more convenient way (you don't need to store somewhere which groups you've left etc.)
Читать полностью…
In the post about software engineers' burnout I briefly mentioned cargo cult programming patterns. Recently I got an insipation to introduce one notable example of them.
Callbacks. Normally callbacks serve for "lazy" or asynchronous execution. When precomputing some data has high pure computation costs, may trigger unnecessary invocation of garbage collector on big chunk of data. When part of computation is outsourced to other components/systems which live their life, and can parameterize computation with their own data (a very notable example is the client-server interaction when server can use internally stored data along with client's data, "agent" callbacks). I.e. when computation triggers long pause at some moment. So asynchronous/"lazy" execution of code can be explained as doing a big working task X (executed by both agents Alice and Bob) in two separate smaller tasks: one for Y thing, one for Z thing, Z depends on Y, Y is executed by agent Bob, Z is executed by agent Alice. So executing "X(Alice, Bob)" is turned into executing "Y(Bob, () -> Notify(Alice, "can-do", Z))". And thus while Bob executes Y, Alice can do other things without waiting for Bob. When Bob finishes his task, he notifies Alice that she can do task Z. And thus Alice and Bob do their work in more efficient way, than if she and Bob executed the task X together.
However, I saw misuse of callbacks in code several times. This was in a code like this:
const funcX = () -> {
const something = () -> {
return anObject;
};
return funcY("somedata", something());
};const funcX = () -> {
return funcY("somedata", anObject);
};
It's a default on time.
Читать полностью…
https://www.youtube.com/watch?v=gKYpvyQPhZo
Читать полностью…
How can individualism and harmonic life come along with each other? Aren't they opposite means?
It depends on how "harmony" is defined. In general it can be thought as an alignment of perception with non-conscious things. And this is where a nature of competition between two core groups plays its role. For the passion-driven group a harmony is usually limited to keeping a good health, walkable space, privacy and peace. And this is achievable even in periods of economic recession or depression. For action-driven group a desire of harmony tends to expand to other people treating them as finite spanning assets, to look greater than them and their neighbors.
So for the passion-driven group both concepts can perfectly match each other. For the action-driven group both concepts are more antagonists to each other.
So a role of passion-driven group is as usual to minimize environmental damage from intraspecific competition of action-driven group. That's why public technical education and open-source are important now. They eventually lead to more broader, less monopolized markets which minimizes environmental damage. Though it may sound paradoxically to those who continue to believe in "good will of almighty closed-circle companies and unions".
What separates my vision on modern technology from default technocratic view is that I don't believe in continuous infinite expansion of particular technological space. Be them software products, ML models etc. I believe in its synergy with humans and older technology instead. Why? For simplicity, take two edge points:
1. Rejection of modern technology and reliance solely on past technologies and human society structures. If they're absolutely good, then why they eventually collapsed and focus shifted to modern forms?
2. Believe in continious infinite expansion of technologies X. If this is good, then why was manual labor (ex. cooking) not fully automatized by machines? Why software does not fully automatize human effort in data processing (for this reason we have separation between "frontend" and "backend" applications)? Why didn't ancient lead plumbing continue its expansion and it regressed towards older water wells until 18th century steel plumbing?
So it seems that these two radical but fantastic points can't explain real progress of technology. But if technology is viewed mere as a way for increasing efficiency of human production and explorative capabilities, then these questions may be answered in convenient way. If technology works against locus of human control, then this technology is eventually abandoned.
Technology progress is no different from biological evolution in this extent. There are no gigantic spiders, there are no microscopic mammals etc.
So from this synergetic view on technology my current lower level vision is derived.
https://www.youtube.com/watch?v=vwag5XE8oJo
Читать полностью…
I think, the main problem of burnout of software engineers lays in keeping the same simplistic behavior patterns for several years. Be them either simple obedience or too authoritarian style of critics and proposals. Autistic engineers especially struggle from these patterns (besides just intransparent culture and communications which cannot be handled individually) leading them either to learned improvement or drowning into poverty sink.
I think, best behavior lines lay somewhere in the middle. You can't implement a solution that has a good engineering value (correctness, simplicity, flexibility for addons etc.) without forcing an order of concerns. As most problems with "endless" bugs and spaghetti code lay in that people usually can't tell clearly what they want from software product. Either because of their limited vision with maximalist desires, or because they have too low trust for engineers (however this can be solved with isomorphic abstract entities: ex. substitute "an s-coin" with "a fun gem" but structure remains the same). So my position for this is to talk until I get necessary preconditions and postconditions for implementation (I'm not of type of a "sonic sports player", leave this for masc phenotypical people). That's how I once implemented one feature for which no ready tools were present, in one iteration without bugs meeting pretty short deadlines (it was 3-4 days before X-Mas).
However, you can't simply enforce your suggestions and questions. Otherwise, you will be claimed as "toxic authoritarian guy". People needs a feedback. A positive feedback provides them a more sense of value of their actions. A negative feedback does the opposite. Negative feedback should not break their hard incentives (this is hard to know for ASD-ie from the first place, though I follow a "socialized autist" path with periodic informal meets). Otherwise, what's called as "loosing trust" happens. This is like constantly DDoS-ing some service in wish that it removes some noisy popups from their site. But it bans your IP instead.
I love synergy of ML technologies with indie web and home aesthetics. It's fun and comforting ^^
For this purpose I crafted a bot based on PromptQL. And I explained how to use capabilities of the language for crafting bots in this Medium article:
jzx777/making-bots-with-promptql-prompts-composition-2a6a7acb30ae" rel="nofollow">https://medium.com/@jzx777/making-bots-with-promptql-prompts-composition-2a6a7acb30ae
#PromptQL #llm #LocalLLM #Llama #golang #go #programming #opensource #library #programminglanguage #promptengineering #prompts
#cottagesoftware #craftprogramming #indieweb
#medium #article #blog
Indie web + Indie AI = ❤️
FRFKBQXAAIAIPHPXLDWATUCTF
I feel sick. I'm stopping posting until things get better.
Читать полностью…