Методология

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
* водолет / e-foilwaterfly / e-foil
* обиКолелоroundaBike
* направи самdo it yourself

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

>> #OpenToWork <<