Ме­то­до­ло­гия

Methodology

Тук с ня­кол­ко ду­ми ще обяс­ня за как­во ста­ва въп­рос в то­зи про­ект.

A few words about what this project is about.

Един са­мо-ци­тат:

соф­ту­ер се пи­ше от хо­ра и за хо­ра.

иг­но­ри­ра­не­то на то­зи прост факт во­ди до всич­ки въз­мож­ни ло­ши пос­лед­с­т­вия. На хо­ра­та тряб­ва да им е при­ят­но да пи­шат соф­ту­е­ра (И съ­от­вет­но от дру­га­та стра­на - да пол­з­ват соф­ту­е­ра), ина­че не се по­лу­ча­ва.

Вся­как­ви­те тех­ни­чес­ки под­роб­нос­ти / ар­хи­тек­ту­ри / ма­ши­ни и пр. са на­пъл­но вто­ри­чен еле­мент в пи­са­не­то на соф­ту­ер. В ни­ка­къв слу­чай не поз­во­ля­вай­те те да над­де­ля­ват.

Учас­т­ни­ци­те в един от­бор тряб­ва да си има­ме ДО­ВЕ­РИЕ и да мо­же да се раз­чи­та из­ця­ло един на друг. Ина­че ни­що ня­ма да ста­не.

citing myself:

software is being written by people and for people.

Ignoring this simple fact leads to all possible bad consequences. People should feel good when writing the software, otherwise it does not come out. And respectively, on the other side - when using the software.

All them technical details - architectures / engines / organisational processes et al - are completely secondary elements in the writing of software. By no means allow them to prevail.

We the participants in a team must TRUST each other and be able to rely entirely on one another. Otherwise nothing will come out.

Ето ня­кои от из­пол­з­ва­ни­те ос­но­во­по­ла­га­щи прин­ци­пи в пи­са­не­то на соф­ту­ер:

Here are some of the basic principles of writing software, used in the project:

• вся­ко пар­че си има соб­с­т­ве­ник/ от­го­вор­ник. То­ва обик­но­ве­но е ос­нов­ни­ят му раз­ра­бот­чик (но мо­же и да не е), и Е то­зи кой­то от­го­ва­ря за не­го и без не­го­во съг­ла­сие не мо­гат да се пра­вят про­ме­ни. То­ва осо­бе­но ва­жи за вън­ш­ност­та, т.е. огъв­ки­те-ин­тер­фей­си.
• each piece has its owner/ person-in-charge. This usualy is its main developer (but does not have to be), and IS THE one who is responsible for it and nothing should be changed without hir consent. This is especialy so for the exteriors, i.e. wrappers-interfaces.
• вся­ка жа­ба да си знае гьо­ла, или все­ки да иг­рае със соб­с­т­ве­ни­те си иг­рач­ки (прин­цип на Де­ме­тър). Час­тен слу­чай:
  - яс­ни и твър­ди ин­тер­фей­си/про­то­ко­ли (ко­е­то не зна­чи не­гъв­ка­ви), с яс­ни изис­к­ва­ния, и "соб­с­т­ве­ност".
  И ни­как­во бър­ка­не под ма­са­та.
• each frog knows it's puddle, or everyone plays with his own toys (Demeter's principle). Special case:
  - clear and firm interfaces/protocols (which does not mean inflexible), with clear requirements, and "ownership".
  And no monkeying under the table at all.
• Раз­ряз­ва­не на оп­ти­ма­лен брой вер­ти­кал­ни сло­е­ве и въз­мож­ност за хо­ри­зон­тал­ни раз­к­ло­не­ния. (Пред­с­та­ве­те си слой в сте­на, със­то­ящ се от ед­на хо­ри­зон­тал­на гре­да от край до край, и на­ре­де­ни от­го­ре тух­ли, и от­го­ре още ед­на гре­да. Гре­ди­те са об­щи­те ин­тер­фей­си на­го­ре/на­до­лу, до­ка­то тух­ли­те поз­во­ля­ват раз­рас­т­ва­не в дру­ги по­со­ки / из­ме­ре­ния (нас­т­ра­ни/нап­ред/на­зад). Не е за­дъл­жи­те­но гор­на­та гре­да да е от­к­рай док­рай - мо­же да има ня­кол­ко над­с­т­рой­ки ед­на до дру­га.) Нап­ри­мер: слой пот­реб.ин­тер­фейс, с ед­но го­ля­мо раз­к­ло­не­ние ек­ран, с под­раз­к­ло­не­ния раз­ни­те gui-api-та...; и дру­го раз­к­ло­не­ние web-browser-ин­тер­фейс, и 3-то - .PDF и дру­ги по­доб­ни са­мо-за-че­те­не пред­с­та­вя­ния.
• Splitting into optimal number of vertical layers and possibility for horizontal branching. (Imagine a layer in a wall, consisting of one horizontal plank end to end, and bricks on top of it, and another plank on top. The planks are the common interfaces towards up/down, while the bricks allow growing in other directions / dimensions (sideways/ forward / backward). The top plank does not has to be end-to-end - there could be several overlayed structures next to one another.) Example: layer user-interface, with one big branch for screen, with subbranches of the misc.gui-api's; and another branch web-browser-interface, and third one - .PDF and similar read-only representations.
• 360' гра­ду­са про­уч­ва­те­лен ог­лед на вся­ко изис­к­ва­не / ин­тер­фейс / _по­со­ка_. Т.е. от­бе­ляз­ват се всич­ки не­ща ко­и­то не­що­то тряб­ва да пра­ви И всич­ки ко­и­то НЕ тряб­ва да пра­ви. То­ва поз­во­ля­ва да се знае ко­га по­со­ка­та на дви­же­ние е греш­на - ако тръг­не към не­що ко­е­то не тряб­ва да се пра­ви. Всъщ­ност те­зи 360' тряб­ва да се счи­тат не ка­то кръг, а ка­то спи­ра­ла; все ед­но лъч на ра­дар, кой­то оби­ка­ля. То­ва поз­во­ля­ва ед­но и съ­що мяс­то да бъ­де об­хо­де­но ня­кол­ко пъ­ти, в ед­но или раз­лич­ни по­ко­ле­ния на про­дук­та (ал­тер­на­тив­ни ре­ше­ния или по­доб­ре­ния)
• 360' degrees exploration view around each requirement / interface / _direction_. That is, noting down all items which the thing must do, AND all those it must NOT. This allows to know when moved into wrong direction - if going towards something that's in the NOT-list. Actualy these 360' should be regarded not as circle, but as spiral; same as radar's beam going round and round. This allows to walk through same place several times, in same or in different generations of the product (alternative solutions or improvements).
  • Ето ед­но по­лез­но пред­с­та­вя­не на изис­к­ва­ни­я­та: пред­с­та­ве­те си соф­ту­е­ра ка­то един ви­сок кол, вър­зан със мно­го въ­же­та - вся­ко от тях пред­с­тав­ля­ва­що изис­к­ва­не / кли­ент / по­со­ка на раз­ви­тие. Раз­лич­ни­те въ­же­та са раз­лич­но де­бе­ли/елас­тич­ни, и раз­лич­но дъл­ги (и са вър­за­ни на раз­лич­ни мес­та - не за­дъл­жи­тел­но в кръг). За­да­ча­та е: Ко­лът да не пад­не, да не се счу­пи и да е с ми­ни­мал­на дъл­жи­на. Нап­ри­мер ако има мно­го въ­же­та от ед­на­та стра­на и мал­ко от дру­га­та, пре­мес­те­те ос­но­ва­та на ко­ла в та­зи по­со­ка (ина­че ще има из­лиш­но дъ­лъг кол сто­ящ мно­го нак­ло­нен). Мо­же и да се вко­пае, и то­га­ва ня­ма да па­да, но пък изоб­що не мо­же да се мес­ти и поч­ти не мо­же да се нак­ла­ня - ще се счу­пи. Съ­ща­та пред­с­та­ва ра­бо­ти и при пов­ди­га­не / удъл­жа­ва­не на соф­ту­е­ра/ко­ла - ня­кои въ­же­та ня­ма да поз­во­ля­ват, и т.н...
  • Here one useful way to picture the requirements: imagine the software as a tall pole, tied with many ropes - each being a requirement / customer / direction of growth. The ropes are differently thick/ elastic, and of different length (and are tied to different places - does not have to be a circle). The task is: the Pole should not fall down, break, and be of minimal length. For example if there are too many ropes on one side and much less on other, shidt the base towards the many - or there'll be a too long and too tilted pole. It can be dug into ground, it thus it won't fall, but then it cannot be moved at all not tilted - and it would break. The same notion works with raising / lengthening the pole / software - some ropes won't allow, etc...
• ези­ци, ези­ци и пак ези­ци - Ези­ци­те за прог­ра­ми­ра­не _са_ ин­с­т­ру­мен­ти­те на прог­ра­мис­та. Всъщ­ност все­ки ин­тер­фейс пред­с­тав­ля­ва един ма­лък език - но то­ва е па­сив­но­то въз­п­ри­я­тие. Ак­тив­ни­ят на­чин е да се пол­з­ва нав­ся­къ­де под­хо­дя­щи­ят език, съ­от­вет­но да се _пра­ви_ език на вся­ко мяс­то къ­де­то има нуж­да / се виж­да пол­за от то­ва - напр. ако сми­съ­лът на при­лож­на­та об­ласт е дос­та­тъч­но от­де­лим / от­не­сен. Ни­как оба­че не е за­дъл­жи­тел­но то­зи език да има нов син­так­сис - пол­з­вай­те син­так­си­са на ба­зо­вия език (в слу­чая пи­тон) ка­то но­си­тел, но вло­же­те соб­с­т­вен сми­съл във все­ки ваш "опе­ра­тор". Ни­къ­де не се изис­к­ва да­ден про­дукт да е на­пи­сан _са­мо_ на един език - то­ва е не­въз­мож­но.
• languages, languages and more languages - Programming languages _are_ the tools of the programmer. In fact each and every interface is a small language - but this is the passive perception. The active one is to use for each place a language that suits it best, respectively to _make_ a language where one is needed / an advantage is seen - e.g. if the meaning of the application field is well separatable / abstract. But it is not at all mandatory to have different syntax for each language - use the syntax of base language (python in our case) as carrier, but put your own meaning / semantics in each "operator". There's never a requirement that a product has to be written in _same_ language all over - it is impossible to do so.
  • Тук за ос­но­вен език се пол­з­ва Пи­тон - ин­тер­п­ре­ти­ран език, поз­во­ля­ващ мак­си­мал­на гъв­ка­вост и мощ при ми­ни­мал­ни уси­лия. Лес­но раз­ши­ря­ем на­до­лу (огъв­ки за С биб­ли­о­те­ки и пр), и лес­но раз­ши­ря­ем на­го­ре (всич­ко е обек­ти, вклю­чи­тел­но фун­к­ци­и­те и кла­со­ве­те - и ме­так­ла­со­ве­те). Т.е. мо­же­те да вло­жи­те в да­ден син­так­ти­чен/гра­ма­ти­чен из­раз ка­къв­то си ис­ка­те сми­съл - сти­га да си го на­пи­ше­те (т.е. да си под­ло­жи­те ме­ко). В на­чал­ния про­то­тип има из­мис­ле­ни око­ло 6-7 ези­ка за опи­са­ние на раз­лич­ни­те еле­мен­ти - поч­ти всич­ки ба­зи­ра­ни на пи­тон (ка­то дек­ла­ра­ти­вен син­так­сис) - но със соб­с­т­вен сми­съл.
  • The main language here is Python - interpreted language, allowing maximal flexibility and power with minimum effort. It is easy extendable downwards (wrappers for C libraries etc), and easy extendable upwards (everything is objects, including functions and classes - and the metaclasses too). That is u can put whatever meaning in some syntactical/grammatical expression - as long as u write it yourself ("cushion" yourself softly). Even in the initial prototype there are 6-7 languages describing various elements - near all based on python itself (as declarative syntax) - but with their own meanings.
• ЧО­ВЕШ­КА­ТА стра­на на прог­ра­ми­ра­не­то е ИЗ­К­ЛЮ­ЧИ­ТЕЛ­НО ВАЖ­НА. До­ри всич­ки­те ра­ци­о­нал­ни и ло­гич­ни пра­ви­ла на све­та да се спаз­ват, ако то­ва се пра­ви ме­ха­нич­но, ни­що ня­ма да се по­лу­чи. В края на кра­и­ща­та, соф­ту­е­рът е _са­мо_ ед­но дос­та ог­ра­ни­че­но от­ра­же­ние на дейс­т­ви­тел­ност­та, на­чин за (оря­за­но) за­пом­ня­не и из­пъл­не­ние на чо­веш­ки зна­ния (в ня­ка­къв пред­ва­ри­тел­но за­ло­жен кон­текст). Ако ед­но зна­ние е прос­то за­пи­са­но в кни­га, тряб­ва ня­кой чо­век да го ин­тер­п­ре­ти­ра и да го из­пъл­ни; соф­ту­е­рът+ма­ши­на­та за­мес­т­ват час­тич­но то­зи ня­кой. Раз­ли­ка­та е, че чо­ве­кът мо­же сам да про­ме­ни по­лу­че­но­то зна­ние (и да го при­ло­жи в пре­ди не­въз­мож­на об­ласт / кон­текст - или да прос­то да обър­ка всич­ко). Ма­ши­на­та не мо­же да обър­ка, но и не мо­же да се оп­ра­вя в нов не-за­ло­жен/пред­ви­ден в нея кон­текст. Та­ка че всъщ­ност упот­ре­ба­та на соф­ту­ер е един из­к­лю­чи­тел­но из­к­ри­ве­но-опос­ред­с­т­ван на­чин за вир­ту­а­лен раз­го­вор с прог­ра­мис­та И спе­ци­фи­ка­то­ра. За­то­ва има зна­че­ние да­ли той е щас­т­лив/ ки­сел/ прок­лет/ мър­зе­лив/ без­раз­ли­чен - въ­об­ще ка­къв е всъщ­ност.
• The HUMAN side of programming is EXTREMELY IMPORTANT. Even if all them rational and logical rules of the world are respected, if it is done mechanicaly, nothing useful is gonna come out. All in all, the software is _just_ a very limited reflection of reality, a way of (clipped) storing and executing of human knowledges (in whatever context, set upfront). If some knowledge is simply stored in a book, a human is needed to interpret and execute it; the software+machine can partialy substitute that person. The difference is that the human can change the received knowledge (or apply it into before impossible area / context - or just mess it up). The machine cannot mess it, but it can't manage a new context either, in one that is not set/ predicted in it. Thus the usage of software is actually an extremely crooked-and-intermediated way of a virtual conversation with the programmer AND the specifier. Therefore, it is important if they are happy/ sour/ bad-tempered/ lazy/ indifferent - what are they actually.
• де­бе­ли­те то­мо­ве са за на­чи­на­е­щи­те.. опит­ни­те си из­мис­лят са­ми пра­ви­ла­та, ко­и­то най-пас­ват на тях са­ми­те и на си­ту­а­ци­я­та.
  Но Най-опас­ни са те­зи ко­и­то не ис­кат да зна­ят че не зна­ят.
  • 3 ни­ва на слу­ша­те­ли­те: ThreeLevelsOfAudience
  • 4 ни­ва на зна­ни­е­то: FourLevelsOfCompetence
  • 5 ни­ва на нез­на­ни­е­то: The Five Orders of Ignorance
• the thick volumes are for beginners... the experienced make their own rules, which best match themselves and the situation.
  But most dangerous are those who do not want to know that they do not know.
  • 3 levels of audience: ThreeLevelsOfAudience
  • 4 levels of knowledge: FourLevelsOfCompetence
  • 5 levels of ignorance: The Five Orders of Ignorance

Те­о­рия и по­со­бия

Theory and books

• Ето ед­на го­то­ва ме­то­до­ло­гия (про­цес), ко­я­то съм на­ме­рил и пред­ла­гам, ка­то не­що го­то­во, съб­ра­но на­куп и кон­сис­тен­т­но - и из­п­роб­ва­но.
  - CrystalClear - Ме­то­до­ло­гия за мал­ки от­бо­ри (до 8) при мак­си­мал­на ефек­тив­ност и "удо­вол­с­т­вие" A methodology (process) i have found and suggest, as something ready to use, all-in-one and consistent - and well-tried out:
  - CrystalClear - Methodology for small teams (up to 8) in maximal efficiency and "pleasure" - amazon.com
• Ос­но­вен ре­сурс (учеб­ник, ако ще­те) на те­ма (чо­веш­ка) ме­то­до­ло­гия/ор­га­ни­за­ция за пи­са­не на соф­ту­ер, е та­зи кни­га: The main resource (call it textbook) about the (human) methodology and organisation for making software, is this one:
  - "Organizational Patterns of Agile Software Development" - amazon.com
• виж спи­съ­ка с пре­по­ръч­ва­ни­те че­ти­ва see the list of recomended readings

Детски нещаKids' things
* книжкиbooks
* творения:легоcreations:lego

БиблиотекаLibrary
* снимкиphotos
* хайкуhaiku
* Коджа кая 2019Kodzha kaia 2019
* направи самdo it yourself

софтуерът-и-азsoftware-and-i
* биоcv