Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Quality in embedded solutions

I want to share experience achieved in electronic gaming of chance. This article may be important for all interested in quality.

Disclaimer: This article has as main goals to turn attention onto unclear things and underwater rocks. So many clear things are skipped ever there where they need for some reason. Also almost all statements are based on long, extensive and meticulous researches and investigations.

Introduction

In the first version of this article I was detailed and precise but all reviewers found out that version too bored and inaccessible. So current version is simple, accessible, funny and full of fun ;)

1. Quality definition

There are a lot of quality definitions. Most of them we can find at wikipedia/Notable_definitions. But in Embedded we can let:

Quality ≈ reliability

and mention some attributes of quality embedded product:
1. Reliability itself;
2. Stability and predictable behavior;
3. Matching of declared and real behavior;
4. Matching of declared and implemented functions and features.

As a reference of the most quality system we can take sunrise ;).

Because:
1. we trust sunrise every morning;
2. we can predict the moment of sunrise;
3. sunrise, as every embedded product, sometimes fail on very seldom basis.

2. Quality Metrics

In steps to deal with quality, such as improve or monitor we need to measure it using some metrics. As far as we let in previous paragraph in Embedded we can let:

Quality metrics ≈ reliability metrics

I want mention most useful of them:

1. MTBC (Mean time between crash)
2. MTBF (Mean time between failure)

In my systems I achieved MTBC ≈ 20 years. So 20 years, in mean, no reboots, resets, repairs and like for every product. It is something outstanding on that market and our customers liked it.

And according to huge number of legends we can take as a reference:

MTBC ≈ 2000 years

for the most quality system from previous paragraph ;)

3. Basics of quality

The quality of final product start from quality of every single component. The key of the quality is setup of production process.

HW Staff

1. No Chinese connectors, switches, rele, and like;
2. No national (CIS) or Chinese PCB;
3. No Chinese wires.

Assembling — soldering

Some time ago instead of mature Pb soldering technology was introduced a set of pb-free technologies. So quality in relationships with soldering technologies:

1. only Pb — excellent;
2. only ROHS (pb-free) — bad. Ever Swiss producers was not able to provide acceptable quality using this type of technologies;
3. mixing of Pb and ROHS — very bad. This case provide too much mystics and strange and unpredictable behaviors.

4. Unification and replaceability of HW and SW components

What is bad for people is good for quality:

in software and in hardware ;)

5. SW Architecture

Hardware and System Simulation Layer

So Simulation Layer was implemented in DSL and DSL interpreter was implemented separately. It was excellent invention of my friend and was one of keys of quality of our products because:
1. No memory allocations;
2. No pointers;
3. No distracting details;
4. Only game flow.

6. Key technology and technics

So following software technologies and technics allow us to provide so hi quality:
1. TDD + DSL
2. Automated and non-interactive debugging such as vallgrind + strace + logging + ...
3. Code generators (cog). Everything what can be generated must be generated, because it avoid human factor in critical moments;
4. Cross-platformity. Sometimes compilation of code for another platform show hidden bugs for original platform.
7. Custom Workflow

So quality projects definitely need dedicated workflow engineer or dedicated workflow activity. Well-known and popular workflows usually are not enough effective. Also our workflow had following key moments:
1. TDD;
2. Dedicated QA activity. Not just testing but researches and investigation in quality;
3. QA on every step;
4. Dedicated integration activity;
5. Brain Storm;
6. Automated and non-interactive debugging;
7. Static code analyzing;
8. Automated testing.

Specifically I want to turn attention than we didn’t need codebase stabilization phase.

8. Team Members

So not all of team players have same importance in achieving good quality of target product. According to my experience I want to mention following team roles:

1. Dedicated quality engineer.
In embedded if you want to achieve excellent results generic testing activity is not enough. So you need to provide all the time explicit researches and investigations in quality specific for you project.
2. Dedicated maintainer.
When particular team members switch from task to task they lose image of overall target project. So role of this player is to watch for consistence of overall project in independence of implementation processes.
3. Wide-area specialists are much more critical than narrow-area guru.

If you will create a team of narrow-area guru and give them embedded project for implementation they will fail them with 90% chance just because they will not understand each other.

9. Bad friends

So this guys will move your project in directions opposite to quality:
1. SCRUM;
2. Agile;
3. KANBAN;
4. Cont. Int;
5. Other modern fashion words.

Yes, often we need to balance in triangle above with help of that guys, but just now I’m talking about quality as much as possible.

10. Inconsiderate decisions

Using this technologies has killed many ideas, startups and companies. It is better ever don't try them.

11. С++

When I saw C++ at the first time it look so beautiful, powerful and cute like this animal:

But when I tried to use it, it already wan not be so cute and I was not able to deal with it by unweared hands:

The most disappointing was that it is too often impossible to fit C++ object code into common platform ABI.

So my final feeling about this language is like this:

Some of significant C+±related issues:
1. Bad exportability of functionality via “extern C”, so we must limit C++ by C-compatible subset OR use OS-specific tools like IPC.
2. Bad handling of exception: too slow and non-reliable. I think some people know about “lost exceptions”.
3. If one of component is written in C++ — usually it affect all other components of product.
4. High cost of support: average Embedded-programmer knows about 20% C++ but at this time everybody knows his own 20% which most likely will be inaccessible for somebody other.
5. Very bad consistency.

So C++ was interested experiment but nothing more. I finally suggest to everybody to avoid C++ in new projects if you don't have clear understanding and really significant reasons to relationships with this angry animal.

And if you still need C++ like OOP I strongly suggest to look on Ada. Ada miss almost all C++ issues and on the Internet you can find a lot of success story of using Ada in embedded.

12. USB

As far as every good embedder knows USB is not more than well-known experiment of Indian students with all related consequences. USB is good as element of HMI or for updating and maintenance embedded device, but no more. So every good embedder prefer to don't use USB as sensor interface, components interconnect or storage interface.

The main problem of USB is unsuccessful design: sometimes host or function can fit into situation like this ass:

and block all USB exchange until human intervention. For that who still want USB there are science researches, investigations and thesises about how to deal with it, and also HW-SW commercial solutions, for example, from Analog Devices.

But also there are some useful tricks which can significantly improve situation:

1. Well-known mature optical isolation, or some other kind of galvanic isolation:

2. Earthing

Yes, this tricks don't solve main USB trouble, but you will fill yourself like ass much more seldom.

13. Windows

There still are a lot of naive who believes in MS and Window. Because this piece of famous art:

we can see in embedded products up to ten times more often, than on regular desktop, I perceive that naives like this keen guy:

So, I believe, one of that guys in the nearest future will be nominated for

14. Native threads

This picture illustrates how I see generic multi-threaded application:

Really usually there are no reason to use threading in Linux userspace at all. Because threading is just increasing complexity and no more. If your task is really heavy to utilize all cpu core resource distributing load on second cpu core using threads will be the worst of possible solutions. Yes, it can be usable for some exotic tasks in HPC environment, but if you still want Linux userspace threads in embedded just recall Alan Cox:

A Computer is a state machine. Threads are for people who can’t program state machines.

And for expanding your horizons read here.

My main points about threads:
1. Threads are usable until they are too simple.
2. Reasons which caused introducing posix threads into Linux is not actual today.
3. On x86 HW threads made ineffective caching, TLB and CPU pipeline. So threads usually made application slow and luggy.
4. Good multithreaded application, in steps to be effective, must know almost everything about underlying HW, what lives in kernel platform code and is not exported to userspace in simple way. Here I bring greetings to JAVA guys ;).
5. Avoiding threads we avoid few classes of possible errors. The main one is thread synchronization errors.

Also we can get some cookies and benefits using cooperate or other kind of manual multithreading like this:

It allow us to handle most of issues from list above.

15. Mixing of FrameWorks

Mixing different frameworks inside of single applications is also a good root of nuances and unpredictable behavior.

Just for illustration: if you use Qt and Gtk+ simultaneously you can't safely use any common way to run child application.

So if you mix different frameworks you can trust your application in same way as you trust gypsy foreknow future.

16. Summary

A paradise of developer

So having so more benefits from DSL we spent a lot of time in finding a way to avoid DSL developing effort in small applications. Finally we found than we can use variant of event driven development: direct programming in finite state machines. It's good and flexible because:

1. FSM can be instantiated in multiple equivalent representations and converted between them.
2. FSM is very simple to learn and is known to every good engineer.
3. FSM is simultaneously enough hi-level to don't worry about implementations and at same time allow low-level operation in natural and flexible way.
4. You have simple and accessible way how to explain for non-programmer engineers what and how you software do.

And finally main benefit: FSM can have same graphical and binary machine representation. So you don't need to use debugger to find a trouble, because on top of good FSM engine FSM work in same way as on paper.

Codeless workflow

And here I have tried to illustrate how FSM can change your development workflow of ever avoid coding from them.

So it is good to start from ragel as FSM description language, UML as design environment and Moore machines as base for both of them.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті




66 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Видео в тему: vimeo.com/179121954

Статейка забавная. Хотя, надо признаться, автор чересчур сгустил краски.

Есть отличная поговорка: «Threads are like salt, not like pasta. You like salt, I like salt, we all like salt. But we eat more pasta». Согласитесь, она одинакова далека как от мнения автора, что треды вообще не нужны, так и от быдло-стайла многих современных горе-программистов, порождающих невменяемо раздутое количество тредов на ровном месте, как впрочем и всех остальных ресурсов. Оптимальный расклад, по моему личному мнению: одно процессорное ядро — один тред.

Да и «китай» не весь плох. Не следует мешать в одну кучу китайский «китай», и «китай» под неусыпным надзором белых людей.

Статейка забавная. Хотя, надо признаться, автор чересчур сгустил краски.

20 лет MTBC на ровном месте не лежат. Кроме того разбавленные краски были довольно скучными.

Оптимальный расклад, по моему личному мнению: одно процессорное ядро — один тред.
Если ты работаешь в HPC то там действительно иногда попадаются задачи где это соответсвует действительности. В эмбеддед я не встречал задач где треды впринцыпе актуальны.
Да и «китай» не весь плох. Не следует мешать в одну кучу китайский «китай», и «китай» под неусыпным надзором белых людей.

Вы наверное как и Майк живете гдето на Цивилизованном Западе. Да я в курсе что китайцы могут производить продукты с вменяемы качеством но ни у на ни у наших поставщиков не получилось выйти на «китай под неусыпным надзором белых людей»

В эмбеддед я не встречал задач где треды впринцыпе актуальны.
Чтобы понять где нужны потоки в embedded можно просто глянуть область применения Freescale i.mx6 quad процессоров. Один из самых любимых процессоров всех кастомеров.
У нас есть кастомер, который нарисовал систему, состоящую из 225 потоков, причём его творчество было остановлено нашей операционной системой у которой лишь 255 градаций приоритетов потоков. Отрасль — Japanese heavy industries.
Отрасль — Japanese heavy industries.

Благодарю. Я почитаю.

У нас есть кастомер, который нарисовал систему, состоящую из 225 потоков, причём его творчество было остановлено нашей операционной системой у которой лишь 255 градаций приоритетов потоков.

Очевидные решения — далеко не всегда правильные решения :)))

Надо было включить Virtualization Extension, создать кучу виртуальных CPU, раздать каждому треду по личному CPU, и вместо градаций приоритетов ОС использовать приоритеты CPU. Если QNX умеет столько процессоров сколько тредов хочет ваш клиент то он был бы просто счастлив что ничем неограничен :)))

А если серьезно, то я бы на quad cpu по доброй воле не согласился бы на больше чем пять тредов: один управляющий и 4 рабочих.

А если серьезно, то я бы на quad cpu по доброй воле не согласился бы на больше чем пять тредов: один управляющий и 4 рабочих.
Вы исходите из того, что ваш процесс будет единолично работать в системе, но это далеко не так.

Я исхожу из того что этот дизайн будет наиболее прозрачным и гибким.

Dear author,

I don’t mean to sound slutty, but please use me whenever you want.

Sincerely,

Grammar

But when I tried to use it, it already wan not be so cute and I was not able to deal with it by unweared hands:

В принципе и не только тут... но лучше перевести на русский, чем портить английский (хоть и не всё совсем плохо)...

“However, when I tried to use it, it was cute no longer and I couldn’t handle it with bare hands.” (это так, чтобы не говорили, что я просто так решила наехать...)

Я отдавал статью на вычитку нейтив спикеру и его рекомендация была следующей:

But when I tried to use it, it already wants not be so cute and I was not able to deal with it by unwearied hands:
it already wants not be so cute

А откуда этот нейтив? О_о

США. Образование: University of Nevada

Ну... такое. Там как МИНИМУМ должна быть инфинитивная форма «wants not TO be so cute» да и то, очень странная форма предложения, Йода бы позавидовал.

Запостила на фейсбуке, посмотрим, что мои нейтивы скажут.

Та нема за що :) Самой интересно стало))

unwearied hands:

Так в тексте по смыслу должно было быть «не уставшие» руки или всё-таки «голые» руки? Так как тут исправили unweared (то, что я думала, было типа «голые») на «unwearied» (что значит «не уставшие»)...

кстати да. здесь он неправ.

www.facebook.com/...19623922.154505.581713922 — должна быть открытой для «публики.» Спросила у своих знакомых.

А зачем понадобилось писать на иглише ЗДЕСЬ? Я всё понимаю, но здесь очень многие изучают язык, и прочтение твоего «English As She Is Spoke» им явно не на пользу. Хотя формально язык в основном правильный, но проблема как раз в «формально». Ты лишаешь читателя собственно мысли, идеи. Здесь не за что зацепиться. Примерно так юристы пишут договора — чтобы человеку было противно это читать, и он подписал не читая.

ЗЫ. Попроси англоязычных френдов проверить текст на артикли. Для наших эта ошибка почти незаметна, мы привыкли без них обходиться.

А зачем понадобилось писать на иглише ЗДЕСЬ?

Я просто опубликовал то что было «как есть».

Категорически не согласен со всем, где есть слово Chinese:

---------------------------
HW Staff

1. No Chinese connectors, switches, rele, and like;
2. No national (CIS) or Chinese PCB;
3. No Chinese wires.
---------------------------


2. Reasons which caused introducing posix threads into Linux is not actual today.
Причём тут потоки, linux и embedded? Слоны, груши и куб.

3. On x86 HW threads made ineffective caching, TLB and CPU pipeline. So threads usually made application slow and luggy.
Этот страннейший вывод основан на каком-то определённом одноядерном процессоре? Слишком категоричный обобщённый вывод сделанный по работе на каком-то определенном железе.
HW Staff

1. No Chinese connectors, switches, rele, and like;
2. No national (CIS) or Chinese PCB;
3. No Chinese wires.

Если вам удавалось наладить поставки качественных комплектующих китайского производства то вы просто везунчик. Мы были вынуждены по всему этому списку переключится исключительно на комплектующие сделанные белыми людьми.

Этот страннейший вывод основан на каком-то определённом одноядерном процессоре?

У меня есть в планах осветить этот момент подробней но покачто не доходят руки.

по остальным моментам мы друг-друга не поймем.

Если вам удавалось наладить поставки качественных комплектующих китайского производства то вы просто везунчик.
Надо ли говорить, что многие мелкие производители комплектующих fabless и на чьих мощностях они производят свои чипы? На вскидку даже такие большие компании как Renesas, Texas Instruments имеют свои фабы в Китае. Касательно PCB — можно сказать, что 70% всех PCB в мире произведено либо в континентальном Китае, либо в островных.
Мы были вынуждены по всему этому списку переключится исключительно на комплектующие сделанные белыми людьми.
Мне чего-то кажется что вы из тех людей, которые заказывали в Китае 2000 плат для своих устройств и делали их у местных подпольных барыг по-дешевле. И основываясь на этой информации экстраполируете на весь Китай. Есть одно золотое правило при работе с китайскими производителями, если предъявляете требования к качеству, никогда не предъявляйте требование к стоимости продукции «не больше такой суммы», а только к качеству. Ну и понятное дело, что ни один хороший фаб не будет работать с мелкими клиентами — это совсем не тот уровень. Популярные у нас сказки о том, что у китайца-исполнителя есть доступ к фабу <подставить знаменитое имя производителя> по ночам, когда там никто не работает ничем как fairy tales не являются %)

Так же как и вывод, что Pb free = RoHS = плохо — это какой-то лично ваш частный случай судя по всему касающийся только припоя. Европейцы уже лет десять, так точно, живут под RoHS, да, это удовольствие недешевое.

Ever Swiss producers
Even Swiss manufacturers? С каких это пор они лидеры в электронике?
по остальным моментам мы друг-друга не поймем.
Думаю, что таки да. Слишком много предубеждений не имеющих под собой реальных оснований.
Надо ли говорить, что многие мелкие производители комплектующих fabless и на чьих мощностях они производят свои чипы? На вскидку даже такие большие компании как Renesas, Texas Instruments имеют свои фабы в Китае. Касательно PCB — можно сказать, что 70% всех PCB в мире произведено либо в континентальном Китае, либо в островных.
Но это ведь не значит, что следующее утверждение неверно:
Если вам удавалось наладить поставки качественных комплектующих китайского производства то вы просто везунчик.

Наладить отношения с китайскими производителями или поставщиками — это такая адская головная боль, что есть целые компании, которые этим занимаются и на этом кормятся. Я уж молчу про одну из популярнейший в Китае профессий для «нашего брата» — контроль качества и контроль отгрузки. Потому что как при производстве китайцы все время пытаются обмануть, так и при отгрузке «забывают» что-нибудь положить в контейнеры. Поэтому я на 100% понимаю Виталия, когда он говорит, что они были вынуждены перейти на комплектующие, сделанные белыми людьми.

Поэтому я на 100% понимаю Виталия
Как ты можешь что-то понимать, если ты вообще ничего не понимаешь в теме?
были вынуждены перейти на комплектующие, сделанные белыми людьми.
Дай мне BOM любой железки, которая сделана «белыми» людьми для начала.

> Even Swiss manufacturers? С каких это пор они лидеры в электронике?

ROHS это не только электроника. Она на все. Ты никогда не видел отметку ROHS например на пластиковых подоконниках? Вобщем швейцарцы первые провели масштабные исследования в этой сфере в попытке изжить свинец из своих иделий. И да — ничего хорошего у них не получилось.

RoHS — это далеко не только свинец.

Я в курсе. Швейцарцы особо сильно ругались конкретно на свинец потому что без свинца у них ничего не получалось сделать с «Эффектом бакенбард».

Отлично написано, хорошо специализированно под доменную область

Дочитал до

Earthing
. Поржал.

Ребята оказавшиеся на месте вышеупомянутого осла не засмеются даже если им предложить услуги екзорциста за большие бабки.

So this guys will move your project in directions opposite to quality:
Could you explain, why, especially for CI?

Because CI aims opposite goals.

CI (and any other practices) could be focused on any goals from triangle you’ve mentioned. And you are speaking about automated tests, static analysis, valgrinding etc — all this stuff is usually part of CI procedures (at least, they could be set up as steps for creation of stable and revertable build). And having quality focus with this is very easy — the only disadvantage of this approach is that devteam will be high-loaded over non-production code writing activities (like “we should correct all Prevent warnings, and we should cover this with autotests, and then we’re getting more warnings from massif/valgrind, we hate this, we want to write something interesting, not this bsht” — this is a common scenario for quality-focused CI processes).

CI, despite word “integration” is not only about integrating any new features, it’s something about “code you’ve committed, is OK”, and it’s usage is crucial, when you can’t afford project structure, like “one person write one big and completely independent feature across the overall project duration”.

You are right for generic applications with CI not so far from centre of triangle. If you move your CI enough close to Quality corner your CI will change so much than nobody will recognize your CI as CI. So it is bad idea to talk about CI if you are enough close to quality corner. It will be something like explaining life in EU using Ukraine/Donetsk as example.

If you move your CI enough close to Quality corner your CI will change so much than nobody will recognize your CI as CI.

CI is very simple concept, and it could be recognized in any corner of this triangle. Generally, CI is just a set of practices, that looks very simple — you do different checks over your code as often, as possible — like “at least per commit”. And CI NEVER make quality worse — it might make huge impact on time (==price, feature delivery time, number of people, who’s doing something other, but writing a production code), because you should fix everything, before you can commit: some unit tests failed — fix this, static analysis shows possible uncertain behavior — fix this, etc. With established CI procedures, you’ll never skip required steps — and here’s the possible problem #1 — you’re unable to make “rapid changes”, like “upload something to make other team member work with this, while you’re still polishing” but rapid changes!=quality.

From my past experience, usual problems with CI over embedded projects are not related to decreasing quality, but with following stuff:
— Hard to create auto-deployable builds for tests in CI. There might be a bunch of reasons for this: device is a kind of commercial secret and we can’t connect it to our network, testing of our changes require to build and deploy the whole firmware (like a few hours task of doing nothing), we don’t have enough devices to use them for something, not related with actual development etc.
— CI practices require to have people, who should maintain overall infra for this. And, depending on how complex your build process is and tests of which complexity do you want to have, such people might cost not less, that True Norwegian Senior Developer. And it’s not always easy to explain to customer, why should he pay for a person, who doesn’t write code.
— CI practices decreasing development velocity, especially, when several people are working in a tight-connected sessions of code. And moreover, having CI-based approach, means, that “fixing and polishing” activities have higher priority, than creation of new functionality.

Yurii, I have used CI in embedded for a few years. And in the most of projects it was no more than just “something on jenkins” or in better situation “a try to be sure than nothing was broken yesterday”. It is the most common opinion or representation about CI I have ever met. I will be surprised if somebody of my colleagues will recognize CI in things you described above. Also I need to mention than my colleagues do the most of embedded at least in Kyiv. So, I think, now you understand what I mean in

If you move your CI enough close to Quality corner your CI will change so much than nobody will recognize your CI as CI.
Yurii, I have used CI in embedded for a few years. And in the most of projects it was no more than just “something on jenkins” or in better situation “a try to be sure than nothing was broken yesterday”.
So, does having experience only with poor CI processes implementation, allows to say, that overall CI is something not necessary?

I have not so much expirience with embedded projects, just something ~3 years. And I’ve seen quite complex — and working well — CI schemes, that really worked for improving quality (at least, when looking for number of issues, found in products during all procedures, requested by CI steps). The biggest issue with it was one, I’ve mentioned before — CI drastically increase non-development people’s time allocation in project. From one side, it’s quite a boring activity for skilled developer, all this polishing of small warnings from static analysis and writing unit tests for each piece of code, from other side, if project is not fixed-bid, customer might want more people “just writing code”, and it’s not easy to show ROI over CI/process-managing activities in a short term. Moreover, quality (and outcome) of established procedures was really varying, based on whether project team had cared over “health” of these procedures.

that overall CI is something not necessary?

Nobody tells it. You don’t understand me because you have never tried to go out from common area in direction to quality corner. Most of categories and practices dramatically change their values and actuality when you go out of common area. There are no sense to talk about common CI not because CI fails there but because CI will change so much than you will be definitely misunderstood.

CI drastically increase non-development people’s time
Just for note: in described experience non-development people’s time was ~50% of total time or some above.
There are no sense to talk about common CI not because CI fails there but because CI will change so much than you will be definitely misunderstood.
Look, CI might change very much, depending on project needs, you might establish more tight procedures over CI-driven verification or more loose, you might use Jenkins, TC or even dedicated build-boy for these activities, but all this still will be a CI.

The OPPOSITE approach to CI is approach, when we’re free to commit and build anything, you could skip static analyzer checks, you could neglect failing unit tests and actually ignore anything outside of scope of your project — until you will reach some defined point (and this point is rare, like once in several months), where INTEGRATION starts — and there you’re ought to fix everything to make it compliant to defined rules.

yes, everything you said does make sense for me, but the context CI was described in is the triangle consists out of time, quality, cost metrics. And the concept here (as I understood) is if you:

  • developing something quickly and of high quality — it will be very costly for you to do
  • developing something quickly and cheaply — it won’t be of high quality
  • developing something of high quality and low cost — it will take a long time

So I agree that CI deals with time and quality metrics, but from another side it comes at a price of staff who maintain it.

Not only staff. It also creates a certain overhead of time, that should be used by developers for tasks, related to CI-following procedures.

Could you be more precise about CI-following procedures?

For instance, in my opinion extending CI with some restrictions regarding to the code style, code coverage etc is more about benefits than something which is required for everyone. But, of course, if we are speaking about a mature environment it is very likely that CI there is configured with the proper metrics and restrictions from the beginning so every developer should deal with standards.

Sorry for possible inconvenience, it should be written as “following CI-defined procedures” :)

General source of this overhead is like following: you wrote some code and you want to commit it (not just to “save”, but also to share to other team members, who need it. But before it will be available, you should make it pass all the checks: code review should be done, tests should be written and passed, checks by static and dynamic analyzers should be performed (f.e. in private builds) and so on. It make a huge number of benefits for quality, but disabling “rapid changes”, if some change to code base should be provided immediately.

Thank you alot, Vitaliy, for the article. I’ve read it in one breath. Could you just give me a hint what EDD stands for from the last workflow diagram (codeless workflow)?

P.S.: Looking forward for your next articles :-)

Event driven development

It’s definitely nice to read articles in English here, but wouldn’t it be better to at least have translated one into Ukrainian or Russian as an option? Mostly for beginners because it still Ukrainian resource.

It can be your English exercises. I just have no time for it.

Time is expensive, that’s for sure :). Personally I prefer to read articles in English and mostly do it. It was just an idea.

And I think it would be fun to write comments in the same language the article is. People already started to do it though.

Grammar-nazi:
Personally I prefer to read articles in English.

expansive значит “расширяющийся”

Юрий Паламарчук:> Grammar-nazi mode off
Юрий Паламарчук:> English mistakes notification redirect to private

Зачем private? Пусть все учатся. Ошибаться не стыдно. Стыдно не учиться.

Sure, it’s not a shame to learn and improve. It’s simply more preferable for others to read comments to the topic instead of error corrections. And after I have corrected my errors your comment doesn’t make any sense.

You should not have corrected your comment. There are people who are willing to learn by mistakes of others.

Your English hurts to read. And you’re trying to be funny too hard.

Your English hurts to read.

I know it but work on it is still in progress.

And you’re trying to be funny too hard.

No. It is just a way I think.

I concur with you, there’s always something to strive for. Good luck!

За последнее время, единственная нормальная статья.
Thanks for article!

Раз уж у нас сегодня English-day, побуду немного grammar-nazi:
Правильно так: Thanks for the article!
Потому что мы говорим не о какой-нибудь абстрактой статье, а именно об этой. Значит, нужен определенный артикль.

I have resisted the urge to be a grammar-nazi for the entire article...

I would like to get detailed feedback about my English ;)

I will be thankfull.

Підписатись на коментарі