- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
#include <iostream>
using namespace std;
const char _Arr_Digit [] = {'0', '1', '2', '3', '4', '5', '6', '7', '8', '9'},
_Arr_Mantissa [] = {'e', 'E'},
_Arr_Sign [] = {'-', '+'},
_Arr_Dot[] = {'.'},
_Arr_Combo[] = {'0', '1', '2', '3', '4', '5', '6', '7', '8', '9', '.'};
const bool DIGIT = false, SIGN = false, OTHER = true;
bool _Call_Mantissa = false, _flag_dot = false, _flag_mant = false;
int _position_mant;
bool Parse_symbol (char _symb, const char* _Arr, int _size_arr);
bool Parse_full_string (string _checking, int _offset, int _amount, bool _sec_cond, const char* _Arr, int _size_arr, bool _Drive);
bool Parse_the_first_symbol (string _checking);
bool Parse_the_second_symbol (string _checking);
bool Control_result (int i, string _checking);
bool Parse_mantissa (string _checking);
bool Parse_full_string_before_mantissa (int i, string _checking);
bool Parse_the_first_symbol_after_mantissa (string _checking);
bool Parse_full_string_after_mantissa (string _checking);
long double Questioning (char s);
long double Questioning (char s) {
string _checking;
while (true) {
cout << "Введите значение " << s << ": ";
getline(cin, _checking);
if (_checking.length() == 0)
cout << "Вы не ввели значение!" << endl;
else if (!Parse_the_first_symbol(_checking))
cout << "Некорректное значение!" << endl;
else return strtold(_checking.c_str(), nullptr); }}
bool Parse_symbol (char _symb, const char* _Arr, int _size_arr) {
for (int i = 0; i <= _size_arr; i++)
if (_symb == _Arr[i]) return true;
return false; }
bool Parse_full_string (string _checking, int _offset, int _amount, bool _sec_cond, const char* _Arr, int _size_arr, bool _Drive) {
bool _parse_flag;
int _parse_count = 0;
for (int j = _offset; j < _amount; j++) {
if (Parse_symbol(_checking[j], _Arr, _size_arr)) {
_parse_count++;
if (_sec_cond) return false;
if (_Drive) {
if (_Call_Mantissa)
_sec_cond = (j == (_amount-1));
if (_parse_flag) return false;
_parse_flag = true;
if (_Call_Mantissa) {
_flag_mant = _parse_flag;
_position_mant = j;
}
}
}
}
if (!_Drive) {
if ((_amount - _offset) == _parse_count) return true;
else return false;
}
else return true;
}
bool Parse_the_first_symbol (string _checking) {
int LENGTH = _checking.length();
bool _parse_cond = (LENGTH < 2);
if (Parse_full_string (_checking, 0, 1, _parse_cond, _Arr_Sign, 1, SIGN))
return Parse_the_second_symbol (_checking);
else if (Parse_full_string (_checking, 0, 1, false, _Arr_Digit, 9, DIGIT))
return Control_result (0, _checking);
else return false; }
bool Parse_the_second_symbol (string _checking) {
if (Parse_full_string (_checking, 1, 2, false, _Arr_Digit, 9, DIGIT))
return Control_result (1, _checking);
else return false; }
bool Control_result (int i, string _checking) {
if (!Parse_mantissa (_checking)) return false;
else if (_flag_mant) {
string _before_mantissa = _checking.substr(0, _position_mant);
string _after_mantissa = _checking.substr(_position_mant + 1);
return (Parse_full_string_before_mantissa (i, _before_mantissa)
&& Parse_the_first_symbol_after_mantissa (_after_mantissa)); }
else return Parse_full_string_before_mantissa (i, _checking); }
bool Parse_mantissa (string _checking) {
int LENGTH = _checking.length();
_Call_Mantissa = true;
bool cash = Parse_full_string (_checking, 0, LENGTH, false, _Arr_Mantissa, 1, OTHER);
_Call_Mantissa = false;
return cash; }
bool Parse_full_string_before_mantissa (int i, string _checking) { // but the first symbol
int LENGTH = _checking.length();
return Parse_full_string (_checking, i, LENGTH, false, _Arr_Dot, 0, OTHER) &&
Parse_full_string (_checking, i, LENGTH, false, _Arr_Combo, 10, DIGIT); }
bool Parse_the_first_symbol_after_mantissa (string _checking) {
int LENGTH = _checking.length();
bool _parse_cond = (LENGTH < 2);
if ((Parse_full_string (_checking, 0, 1, _parse_cond, _Arr_Sign, 1, SIGN)) ||
(Parse_full_string (_checking, 0, 1, false, _Arr_Digit, 9, DIGIT)))
return Parse_full_string_after_mantissa (_checking);
else return false; }
bool Parse_full_string_after_mantissa (string _checking) {
int LENGTH = _checking.length();
return Parse_full_string (_checking, 1, LENGTH, false, _Arr_Digit, 9, DIGIT); }
Westnik_Govnokoda 30.12.2020 08:35 # 0
Westnik_Govnokoda 30.12.2020 08:36 # 0
bormand 30.12.2020 09:18 # +2
Westnik_Govnokoda 30.12.2020 09:44 # 0
bormand 30.12.2020 11:57 # +2
Сходу проектировать функции сложно если опыта нету.
З.Ы. Если ты не можешь за одну короткую фразу сказать что делает функция или класс -- это неудачная абстракция, попробуй по-другому.
CHayT 30.12.2020 14:03 # +3
1) Какую-то часть портянки хотелось бы использовать в другом алгоритме или проекте. Научиться подобно Шики видеть линии в коде так, чтобы переиспользовать его, можно тупо делая несколько проектов: рано или поздно встретится задача, которую ты уже где-то решил.
Вообще, на переиспользуемости кода я бы не рекомендовал зацикливаться, по крайней мере на первое время. Код, который стóит переиспользовать, должен быть крайне хорошо реализованным, протестированным и документированным, и он должен быть универсальным. С этими пунктами даже создатели языков стандартных библиотек языков умудряются обосраться.
2) Для упрощения чтения и понимания кода, чтобы составляющие части алгоритма были изолированы и именованы. Зачастую функция будет использоваться только один раз, и это нормально. В этом случае функция, во-первых, даёт имя какой-то части алгоритма, помогая читателю понять, что хотел сказать автор. И, во-вторых, ограничивает область видимости этой части алгоритма.
Допустим, весь алгоритм целиком работает с 30 переменными. Если он написан одной портянкой, то для его понимания нужно постоянно удерживать в памяти состояние всех 30 переменных. Без лошадиных доз риталина (запрещён в РФ) это невозможно. Теперь разобьём его на вспомогательные функции. Допустим, в среднем такая функция на вход принимает 3 переменных и возвращает одну. То есть они работают с куда меньшим количеством информации, и ментальное усилие, необходимое для понимания каждой из них, становится посильным.
1/2
CHayT 30.12.2020 14:03 # +3
2/2
Desktop 30.12.2020 14:25 # +1
сепульки
CHayT 30.12.2020 14:31 # +1
gost 30.12.2020 14:44 # 0
CHayT 30.12.2020 16:13 # 0
Desktop 30.12.2020 14:50 # 0
потому что юнит-тесты работают с блэкбоксом и на читаемость им в общем-то насрать
bootcamp_dropout 30.12.2020 14:57 # 0
Desktop 30.12.2020 15:12 # 0
bootcamp_dropout 30.12.2020 17:45 # 0
CHayT 30.12.2020 14:28 # +2
Desktop 30.12.2020 14:32 # 0
> Я работал в трёх крупных конторах и должность QA была только в одной
- ошибка выжившего налицо, так сказать. Не надо работать в криптоцыганских стартапах
gost 30.12.2020 14:43 # +1
bormand 30.12.2020 14:44 # +2
defecate-plusplus 30.12.2020 14:49 # +1
CHayT 30.12.2020 15:03 # +1
Desktop 30.12.2020 14:49 # 0
CHayT 30.12.2020 15:02 # 0
Desktop 30.12.2020 15:03 # 0
- почему?
bormand 30.12.2020 15:04 # +1
Desktop 30.12.2020 15:06 # 0
bormand 30.12.2020 15:07 # +1
Desktop 30.12.2020 15:08 # 0
CHayT 30.12.2020 15:09 # 0
defecate-plusplus 30.12.2020 15:08 # 0
на прод можно не каждый коммит, а только тот, который отмечен правильным форматом тега
CHayT 30.12.2020 15:08 # 0
А почему, собственно, нет, если у тебя stateless мелкосервиc с гринблёй?
Desktop 30.12.2020 15:10 # 0
stateless мелкосервиc слабо сочетается с ручным тестированием
в мобайле CI/CD никак не мешает мануальному тестированию и я не понимаю даже, как он может мешать-то
bormand 30.12.2020 15:15 # +1
Desktop 30.12.2020 15:18 # 0
ты настраиваешь CI/CD, чтобы при пуше в фича-ветку он делал билд, гонял тесты и выбрасывал артефакт или орал про ошибки красненьким
при мердже пул-реквеста CI/CD делает то же самое, только ещё заливает билд в систему дистрибуции, откуда его могут забрать тестировщики, попутно сря нужными комментариями в слак и джиру
почему раз в неделю?
bormand 30.12.2020 15:20 # +1
Если у тебя там не тысяча китайцев в подвале, конечно.
Desktop 30.12.2020 15:23 # 0
сливает себе билд с этим номером и тестирует
время на тесты мануальщиком после окончания работ программиста заложено для каждой задачи при планировании и учитывается при наборе спринта
ферштейн?
Desktop 30.12.2020 15:25 # 0
bormand 30.12.2020 15:30 # 0
CHayT 30.12.2020 15:28 # 0
Т.е. в твоём процессе получается, что специально обученный человек прогоняет тесты на артефакте с "integration" и даёт добро на мердж в "stable", и заказчику попадает артифакт со "stable". И где здесь continuous, Desktop?
Desktop 30.12.2020 15:34 # 0
что там концептуально или нет, мне похуй, мне надо деливерить фичи, а не с концепцией танцы танцевать
CHayT 30.12.2020 15:18 # 0
1) Ты заделиверил один мёрдж-коммит, и сразу понимаешь, что в нём баг. Откатываешь сервис на один коммит.
2) Ты разом заделиверил 30 фич, одна содержит баг, и две других меняют схему персистентных данных, и их нельзя откатить, ибо старый код сломается о новые данные.
Какой вариант выберешь?
CD не панацея, и есть ситуации, когда его использовать в принципе нельзя (например, если сервис очень stateful, и любой баг в нём может распидорафтить все данные). Но если его можно использовать, его стоит использовать.
Desktop 30.12.2020 15:20 # 0
я не утверждаю, что CI/CD не нужен, я считаю, что он нужен
я говорю, что он не отменяет возможность ручного тестирования
деливерить можно не только лишь на прод
defecate-plusplus 30.12.2020 15:28 # 0
если ты на прод заливаешь 30 фич, переинтегрированных между собой, то у тебя на это есть причины - очевидно, 30 фич осилились не за 30 спринтов, а за 1 (один, карл), т.е. скорее всего продукт молодой и активно запиливается
гораздо сложнее для молодого продукта тестировать каждый коммит, тормозя остальные 29, это дорого и зло - не важно кто будет тестировать этот коммит, твои тестеры, наемные тестеры, волонтеры или заказчик
CHayT 30.12.2020 15:35 # 0
Первая проблема: у тебя 30 коммитов, а не один. Нужно понять, в каком из них баг.
> если ты на прод заливаешь 30 фич, переинтегрированных между собой (не обязательно! прим. редактора), то у тебя на это есть причины - очевидно, 30 фич осилились не за 30 спринтов, а за 1 (один, карл), т.е. скорее всего продукт молодой и активно запиливается
...Или старый, большой, и монолитный и его пилят 5 команд со своими спринтами.
> гораздо сложнее для молодого продукта тестировать каждый коммит
Больше инстансов дженкинса, больше параллельности тестов.
defecate-plusplus 30.12.2020 15:39 # +1
звучит как проблема на 10 минут, если честно
если ты смотришь в код и не понимаешь как так случилось, то даже зная в каком коммите проблема ты потратишь ~ столько же времени
потому что не исключено, что вскрытая проблема вообще не связана с этими коммитами, а живёт в проде уже пару месяцев
> Больше инстансов дженкинса, больше параллельности тестов.
заказчик должен параллельно 30 версий прода запускать в работу? а потом слать отчеты, что "вот у меня тут как-то не всё работало в 14:18 в среду"?
CHayT 30.12.2020 15:44 # +1
Если у меня один коммит, и после его деплоя прилетает алярм, что количество 500х ошибок выросло на 1%, то я не смотрю в код. В принципе. Я откатываю деплой, и смотрю на логи и код потом в тихой и спокойной обстановке. Или кубернитис это сам делает, останавливает гринблю и меня пингует в ёбаном мессенджере на электроне. Смотреть в логи и код, пока прод подгорает, я тоже умею, но нахер мне такое удовольствие.
defecate-plusplus 30.12.2020 15:47 # 0
ошибка 500 это не единственный признак "ПО работает не так как мы ожидали" и даже близко не
особенно в кейсе @Desktop, который деливерит мобильное приложение
если что, я не оппонирую, мне наоборот интересно где можно (нужно) улучшить наши внутренние процессы
CHayT 30.12.2020 16:09 # 0
Ну естественно. Но если исповедовать религию "let it crash", то это хорошая аппроксимация.
CHayT 30.12.2020 15:47 # 0
У заказчика есть только REST API. Нахер ты ему билды своих облачных микросервисов отдаёшь?
defecate-plusplus 30.12.2020 15:51 # 0
а ты "только рест апи"
CHayT 30.12.2020 15:57 # 0
> Сейчас в заднем конце всюду `CI/CD',
(D as deployment)
Desktop 30.12.2020 15:59 # 0
xD
bormand 30.12.2020 15:56 # 0
Ну видимо требования по персональным данным или ещё какой-нибудь секретности, что заказчик должен на своей инфраструктуре крутить.
CHayT 30.12.2020 16:01 # 0
Ну так это совсем другая ситуация. Тут концептуально появляется понятие релиза, планирования релизов и т.д., и continous deployment улетает в трубу.
j123123 31.12.2020 18:37 # 0
Как мне написать автотест, чтоб он проверял что вот такой-то код на сишке на таком-то STM32 говноконтроллере с такими-то эрратрами будет настраивать вот такой-то кодек (настраиваемый через через I2C шину и передающий-принимающий аудиосемплы в дуплексном решиме по шине I2S) и это будет нормально работать?
bormand 31.12.2020 18:40 # 0
З.Ы. Ну или даже эхо-тест через перемыку, раз он и передаёт и принимает.
j123123 31.12.2020 18:52 # 0
Автотесты ж нужны для какой-то часто меняющейся и хитрым образом переплетенной питушни, когда изменения хуйни1 может влиять на работу хуйни2 самым неочевидным образом.
bormand 31.12.2020 18:53 # 0
Либо если сложная логика, все ветки которой заёбывает проходить вручную.
bormand 31.12.2020 18:55 # 0
CHayT 31.12.2020 19:07 # 0
Ничего вы не понимаете в комфорте. Свои пет-проекты, к примеру, я всегда пилю спросонья, либо усталым, и порой люблю их рефакторить, чтобы не воняли. Я бы в жизни не стал этого делать, если бы не был уверен, что если CI прошёл, то ничего тривиального не сломалось. Ну и руками что-то тестировать мне лень, не барское это дело.
Ну или по работе импелементацию какого-нибудь stateful асинхронного протокола с шестью версиями и десятком полей тоже попробуй руками протестируй. А так один раз написал property-based тестбед с инжекцией ошибок и течёшь. Вкалывают роботы, а не человек.
bormand 31.12.2020 19:09 # 0
CHayT 31.12.2020 19:11 # 0
Ну мы тут про людей говорили, вроде.
bormand 31.12.2020 19:12 # 0
bormand 31.12.2020 18:58 # 0
Ну если эта стабильность важна, конечно.
bormand 31.12.2020 19:10 # 0
CHayT 31.12.2020 19:17 # +1
"10 hours of HEYYEYAAEYAAAEYAEYAA"
gost 31.12.2020 18:40 # +2
j123123 31.12.2020 18:41 # 0
bormand 31.12.2020 18:43 # 0
CHayT 31.12.2020 19:24 # +1
bormand 31.12.2020 21:38 # +2
Кубернетис против реального железа -- это как надувная тян против подушки.
guest6 31.12.2020 21:43 # +1
defecate-plusplus 31.12.2020 21:43 # +3
guest6 31.12.2020 22:48 # −1
они вполне себе виртуаляца уже, вон я недавно про single root I/O virtualization читал: писи ай экс пресс умеет реально вротуализировать тебе несколько сетевых карт (виртуальных функций)
defecate-plusplus 31.12.2020 22:53 # +2
MAKAKA 31.12.2020 22:58 # 0
MAKAKA 01.01.2021 00:19 # +1
guest6 01.01.2021 00:21 # +2
CHayT 01.01.2021 00:29 # 0
bormand 01.01.2021 02:07 # 0
И лики сишного аллокатора?
guest6 01.01.2021 02:31 # +3
Знаете, что такое безысходность?
Это когда берешь стабильную слаку, а докера там нет.
Ставишь slackbuildы со всеми сорока зависимостями, но поставив go, забываешь перечитать профайл, и в PATH у тебя вместо go -- gcc-go, и сборка докера падает от отсутствия понимания параметра buildmode.
Потом ты всё таки ее собираешь, и ставишь docker-compose (собрав еще 10 зависимостей), но он 2018-го года, и не понимает Compose Specification.
Ты пишешь автору слак билда "could u please upgrade хуё-мое", и получаешь ответ от мейлер демона, что такого мыла нет.
gost 01.01.2021 02:33 # +1
bormand 01.01.2021 02:34 # +1
MAKAKA 01.01.2021 02:38 # +2
Каждый месяц кто-то пишет на LQ "а вы видели ченджлог каррента? кажется, скоро у нас будет 15!"
Каждый месяц последние три года.
Но самое смешное, что докера в карренте нет. И нгинкса нет. И постгри. И node.
Зато есть PHP, Apache и squid. Всё хочу спросить у Патрика как ему там в 2006-м?
bormand 01.01.2021 04:22 # 0
Скоро у нас будет 15 лет без релиза?
MAKAKA 01.01.2021 04:37 # 0
bormand 01.01.2021 04:47 # 0
Да проще из генты ебилд спиздить, чем разрабам писать...
Серверный софт всё-таки не десктоп, достаточно чтобы ядро да либцы прокатили.
bormand 01.01.2021 04:55 # 0
Если ты каждую прогу с её зависимостями в отдельный каталог в /opt'е складываешь, конечно. Стандартную помоечку в /lib заебёшься поддерживать если ты не Патрик.
MAKAKA 01.01.2021 05:10 # 0
но зависимости нужно хендлить вручню: к примеру поставить слакбилд с go, чтобы собрать им слакбилд с докером
bormand 01.01.2021 05:20 # 0
В этом и проблема. Невозможно адекватно мейнтейнить стандартную юниксовую помоечку самому. У тебя нет времени и ресурсов на сведение версий либ к общему знаменателю, тестирование совместимости и т.п. Сам же пишешь, что часть слакбилдов морально устарела и не поддерживается. Да и мартышкин труд, т.к. в других дистрах всё это уже сделано за тебя.
Установка каждой программы (программы в смысле "продукта", а не "бинарника") в отдельный каталог вместес нужными ей либами позволяет снизить интерференцию между софтом и хоть как-то выжить. По сути docker way без докера. Я когда-то слаку так и админил.
MAKAKA 01.01.2021 05:30 # 0
Пока в Слаке было три пакета в 1997-м году, он справлялся, а современный юникс требует сотен программ и либ, и можно крянкуть.
Я правда не понял, чем отдельные папки лучше slackbuilds.
Авторы слакбилдов гарантируют тебе совместимость с версией дистра (хочется так думать).
Слакбилды так же умеют себя удалять.
Если ставить в каждую папку вручную, то придется потом ldconfigу рассказывать про либы, не?
Но вообще проще всё запускать в докере, и течь.
Кстати, идею зависимостей породили бздуны.
Сначала у них был только тот софт, что шел в комплекте с ОС (ну как в слаке), но потом они завезли порты с зависимостями, и стало можно поставить софт, которого в стандартной поставке нет, и не ебаться с его зависимостями
bormand 01.01.2021 05:34 # 0
Это ортогональные вещи. Я против установки самосборного говна в /lib. А слакбилды норм, если их подтюнить немного и сменить префикс.
> придется потом ldconfigу рассказывать про либы
Ни в коем случае. Убьёшь весь профит от изоляции.
MAKAKA 01.01.2021 05:37 # 0
>ни в коем случае
а, так ты за то, чтобы вручную в petuh1 и petuh2 поставить нужную им версию libkurochka?
когда я устанавливаю софт методом аутоконф configure make make install, то конечно я его ставлю в /usr/local/petuhsoftname
bormand 01.01.2021 05:41 # 0
Я за сборку каждой софтины (postgres, nginx и т.п.) со своим независимым префиксом. Ну и все либы, которые им нужны -- прям к ним в этот же префикс. В худшем случае LD_LIBRARY_PATH в ланчере придётся добавить.
Это та же самая идея, что сейчас во всяких virtualenv и докерах исповедуется.
А упаковать этот каталог в tgz и ставить через пакетник никто не мешает. В случае слаки тут ещё один профит -- получается ОДИН пакет без зависимостей.
MAKAKA 01.01.2021 05:44 # 0
пусть там будет голое ядро, и каждый софт в своем докер контейнере... как в корос
bormand 01.01.2021 05:56 # 0
А оно к тому и идёт, походу. На серваках везде докер. На десктопах шаттлврот свой snap пропихивает. На телефонах тоже всё изолировано.
Дальше поддерживать /lib -- это тупиковый путь, имхо. Это было круто и удобно в своё время, но сейчас от этого одни проблемы.
MAKAKA 01.01.2021 06:07 # 0
Да и админкам нравилось обновить либу и "пофиксить" сразу кучу софта.
Забавно, что первыми адовость этого говна осознайли майки со своим "dll hell", когда пользователя спрашивали хуйню
Еще Чен смеялся над вопросами установщика типа "вы хотите заменить petuh.dll 2.2.3.3 версией 2.2.3.4?".
Замени, и молись, чтобы ничего не упало нигде.
Прыщевикам было чуть проще, потому что весь софт ставился из единой дырки.
Майки завезли SxS еще двадцать лет назад, просто мало кто пользовался
Ну вот и остальных это конснулось
bormand 01.01.2021 06:10 # 0
Угу. Ну и security фиксы обычно минимальные и ничего не ломают, поэтому минорное обновление либы таки прокатывает.
А вот какую-то фичу, нужную свежему софту, ты будешь ждать полгода до следующего релиза. Или пять, лол, если ты сторонник стабильности.
MAKAKA 01.01.2021 06:16 # 0
но можно сказать, что использование только системного говна дает тебе стабильность. Если я хочу например собирать SNMP с железок и выводить результаты в каком нить MRTG, то мне в общем всё равно какая у меня версия nginx.
А если я буду врунчую запускать докер контейнеры, то вынужден буду не забывать их обновлять бо security, и еще настраивать
bormand 01.01.2021 06:26 # 0
Ну есть же софт, который мониторит версии говна в контейнерах и предупреждает про уязвимости в нём.
> дает тебе стабильность
И отбирает гибкость, заставляя тебя выбирать между "всё стабильное" и "всё свежее". Хотя, по-хорошему, тебе надо всего пару свежих прог, а остальное могло бы быть стабильным.
MAKAKA 01.01.2021 06:44 # 0
Вообще я бы сказал, что есть три разные задачи:
* Сервер приложений, версии софта на котором выбирает РАЗРАБОТЧИК
* Сервер сервисов сети или просто сетевой инфраструктуры, софт на котором выбирает АДМИН
* Рабочая машина ПОЛЬЗОВАТЕЛЯ
Все три сценарии могут требовать разного.
Docker однозначно лучше для первого, и какой-то SNAP для третьего. А вот для второго возможно что ничего этого не нужно
bormand 01.01.2021 06:48 # 0
До первого случая, когда тебе понадобится свежий софт. А потом Сёма себе роутер убивает по советам с форумов, лол.
MAKAKA 01.01.2021 06:51 # 0
ну админы же как-то живут с тем, что для поддержки нового RFC нужно менять версию винды, или там ios, и их это не смущает.
Вот если админ скажет разрабу "мы не можем перейти на новую версию питона, потому что ее нет в дистрибе" это пиздец, лулз, зашквар, и PHP4 на шаред хостинге.
bormand 01.01.2021 07:02 # 0
Не знаю, если честно. Может быть в 2020 году и не понадобится. Для стандартных задач, где можно просто стандартную коробку в духе циски купить и течь.
MAKAKA 01.01.2021 07:16 # 0
bormand 01.01.2021 07:19 # 0
Ну не. Прикрутят очередную хуйню, без которой твои письма пойдут в спам, и весь сервак обновлять?
openldap и какая-нибудь файлопомойка с самбой -- ну х.з., наверное.
А хрень для мониторинга -- отличный кандидат для запуска в контейнере. Тогда её можно будет обновлять реже чем сам сервак.
MAKAKA 01.01.2021 07:25 # 0
ну вот я ставлю говно для мониторинга. Из паетного манагера оно само подымит мне веб сервер, скриптуху на коей писана со всеми зависимосиями, какое нить rddtool, и все нужное говно, да еще и настроит частично само.
А с докером что? Мне или докер компост писать, или делать фет контейнер вручную?
bormand 01.01.2021 07:26 # 0
> фет контейнер
Как что-то плохое. Ты вон вообще в систему проги ставишь ;)
MAKAKA 01.01.2021 07:29 # 0
Так это и будет фэт.
>как что-то плохое
Ну по какой-то причине за это ругают. Я как-то в одном проекте запустил django, cron и gunicorn в одном контейнере, так на меня девопсы до сих пор пальцем показывают.
Алсо, фэт контейнеры должны иметь init (pid 1) процесс по идее, иначе могут быть зомби. Наражаешь детей, да помрешь. А кто их похоронит?
bormand 01.01.2021 07:29 # 0
goto тоже ругают... Но между установкой говна в систему и фет контейнером выбор по-моему очевиден.
З.Ы. Я думаю, за установку джанги без контейнера эти девопсы тебя вообще бы обоссали.
MAKAKA 01.01.2021 07:33 # 0
В моем случае вариант с системой и не канал, кстати: мы деплоились докерфайлом на aws. Там конечно можно вручную всё положить на VPS, но AWS может её в любой момент убить
guest6 01.01.2021 11:36 # 0
defecate-plusplus 01.01.2021 09:20 # +1
А для адекватного контроля детей мы однажды сделали контейнер, где фореграунд процесс был системд, лол. Но насколько я помню, там уже было как раз проще поебаться с системд, чем нагородить большую помойку не совсем классических контейнеризуемых сервисов
guest6 01.01.2021 16:16 # +1
Наш фет был продиктован выбором крона.
Допустим, твой сервис должен каждую минуту нести яйцо.
Если он писан например на жаве или net, то он работает постоянно, и можно (например библиотекой quartz) это красиво решить.
Если же ты скриптушок, то красивое решение это API. А в соседнем контейнере хертбит сервис, который каждую минуту дергает API.
Можно это всё обмазать celery или другим каким-то queue, и потечь.
Но это всё слишком сложно для тупого приложения.
Потому мы сделали как PHPшники: крон сервис, который дерагет наш скрипт раз в минуту.
В джанге даже есть удобный API для этого: пишешь функции, расставляешь аннотации типа "звать раз в час", главное снаружи чтобы кто-то точку входа дергал по крону
bormand 01.01.2021 18:02 # 0
У меня паук на ngk через uwsgi мулов крутился, никаких кронов там не было.
Да и просто так контейнер с долгоиграющим скриптом можно поднять...
guest6 01.01.2021 19:53 # 0
ну вот есть кнтейнер с джангой, там нужно дергать python manage.py итд
Хотя возможно увизги бы нам помог
CHayT 01.01.2021 19:19 # 0
Больные ублюдки. Чем supervisord не подошёл? (Ну или любой другой легковесный супервизор, тысячи их)
defecate-plusplus 01.01.2021 19:29 # 0
Думаешь, супервизорд подойдёт?
CHayT 01.01.2021 19:33 # 0
Какой микросервис )))
defecate-plusplus 01.01.2021 19:37 # +1
Девайс стартует без хостовых иксов, докер делает всё остальное.
CHayT 01.01.2021 19:41 # 0
defecate-plusplus 01.01.2021 19:44 # 0
CHayT 01.01.2021 20:37 # 0
В составе k8s может ещё да, а вот голый Dockerd с компостом держать на долгоживущих хостах — такое. Мне несколько раз приходилось чистить вилкой /var на старых дев-хостах с ним, ибо долгоносик^W докер в нём пожрал всё место под логи или какую-то другую питушню.
defecate-plusplus 01.01.2021 20:43 # 0
Но да, все когда-либо сталкиваются в первый раз с этим.
О, ништяк, команда стала ещё проще
CHayT 01.01.2021 20:57 # 0
defecate-plusplus 01.01.2021 21:02 # 0
Кстати, в центос 7 есть редкая бага в systemd-journald, которая при активном наполнении логов тупо мемличит. Журналд может и десяток Гб рам нажрать таким образом
defecate-plusplus 01.01.2021 21:09 # 0
CHayT 01.01.2021 21:28 # 0
guest6 01.01.2021 20:10 # 0
CHayT 01.01.2021 20:19 # +1
guest6 01.01.2021 20:23 # 0
ты прав, я наверное зря доебался
bormand 01.01.2021 06:15 # 0
Дык можно как в SxS расшаривать и трафик и место и память если так вышло, что двум прогам нужны одинаковые либы. Если более-менее одинаковые версии либ во все пакеты пихать, то норм будет. Что-то отстанет, что-то обгонит, но в среднем будет шариться.
MAKAKA 01.01.2021 06:40 # 0
Если у меня два Dockerfile импортируют одного родителя, то он один качается, а потом они оверлапятся на него вроде
bormand 01.01.2021 06:45 # 0
MAKAKA 01.01.2021 06:47 # 0
MAKAKA 01.01.2021 05:09 # 0
docker-compose, ты не повериш, скачивается прямо отсюда:
https://github.com/docker/compose/releases/download/1.27.4/docker-compose-Linux-x86_64
это вот прямо эльф, со всем говном статически линкованный, и зависящий только от ядреных вызовов
Это же go:)
но я же хотел красиво
CHayT 01.01.2021 12:45 # 0
bormand 30.12.2020 14:19 # +3
Граница между функциями должна проходить в логичных, простых местах, чтобы каждую из них можно было в отдельности рассмотреть и понять, не подглядывая в код соседних. А не просто потому что 10 строк или 30 переменных набралось.
1024-- 30.12.2020 16:46 # +1
Кстати да. Парсинг какого-то одного символа - более мелкая операция, которая входит в состав парсинга всей строки.
Соответственно, читатель ожидает, что
1. Parse_the_first_symbol парсит один символ, а Parse_full_string - целую строку,
2. Parse_the_first_symbol будет какой-то вспомогательной функцией в составе Parse_full_string.
А в коде автор даёт читателю ложную информацию и усложняет чтение кода. Разбиение на функции становится только обузой: чтобы разобраться в одной функции, приходится читать почти весь код, что эквивалентно чтению кода, если бы он весь был в одной функции.
Desktop 30.12.2020 17:05 # +1
bad code matters
bormand 30.12.2020 20:15 # +1
gost 30.12.2020 14:45 # +2
А если в них ткнуть курсором — код развалится?
CHayT 30.12.2020 14:58 # +1
bormand 30.12.2020 14:59 # 0
gost 30.12.2020 15:03 # 0
bormand 31.12.2020 21:45 # 0
Разработанный кругозор.