1. C++ / Говнокод #27187

    0

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    19. 19
    20. 20
    21. 21
    22. 22
    23. 23
    24. 24
    25. 25
    26. 26
    27. 27
    28. 28
    29. 29
    30. 30
    31. 31
    32. 32
    33. 33
    34. 34
    35. 35
    36. 36
    37. 37
    38. 38
    39. 39
    40. 40
    41. 41
    42. 42
    43. 43
    44. 44
    45. 45
    46. 46
    47. 47
    48. 48
    49. 49
    50. 50
    51. 51
    52. 52
    53. 53
    54. 54
    55. 55
    56. 56
    57. 57
    58. 58
    59. 59
    60. 60
    61. 61
    62. 62
    63. 63
    64. 64
    65. 65
    66. 66
    67. 67
    68. 68
    69. 69
    70. 70
    71. 71
    72. 72
    73. 73
    74. 74
    75. 75
    76. 76
    77. 77
    78. 78
    79. 79
    80. 80
    81. 81
    82. 82
    83. 83
    84. 84
    85. 85
    86. 86
    87. 87
    88. 88
    89. 89
    90. 90
    91. 91
    92. 92
    93. 93
    94. 94
    95. 95
    96. 96
    97. 97
    98. 98
    99. 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 Декабря 2020

    Комментарии (146) RSS

    • Сначала проверяется первый символ. Если это "+"/"-" и при этом длина строки больше 1 (иначе — значение некорректное), тогда проверяется второй символ. Вторым символом может быть только цифра (иначе — значение некорректное). Если второй символ валидный, тогда переходим ко второму этапу. Ко второму этапу также переходим, если первый символ цифровой. На втором этапе нужно просканировать всю строку (но начинаем уже со второго символа, если первый символ цифровой, и с третьего, если первый символ "+"/"-", — так как их уже просканировали) на наличие символа "е"/"Е". Если он встречается в строке, то запоминаем его позицию, но если он встречается более одного раза, тогда значение — некорректное, а также значение некорретно, если даже этот символ один, но стоит на последнем месте. На третьем этапе, если был обнаружен символ "е"/"Е", тогда сначала разбиваем исходную строку на две подстроки (первая от начала до символа "е"/"Е", вторая — после него).
      Ответить
    • Затем сканируем первую подстроку: в ней на данном этапе допустимы цифры и одна точка (если встретится более одной точки — значение некорректное). Далее сканируем вторую подстроку: в ней первый символ может быть "+"/"-", либо цифра. Если первый символ "+"/"-" и длина второй строки меньше 2 — значение некорректное, если нет, то сканируем вторую подстроку дальше до конца, начиная со второго символа (допустимы только цифры, иначе — значение некорректное). Если первый символ второй подстроки — цифровой, тогда также сканируем подстроку до конца (допустимы только цифры, иначе — значение — некорретное), начиная со второго символа. Если хотя бы одна из проверок этих двух подстрок показала — некорректное значение, тогда значение всей строки некорректное, иначе – корректное. Если символа "е"/"Е" в строке нет, тогда сканируем строку, начиная со второго символа, если первый символ цифра, начиная с третьего символа, если первый символ "+"/"-". Допустимы цифры и одна точка, если более одной точки, либо встретился хотя бы один левый символ, тогда значение некорректное, в иных случаях корректное.
      Ответить
    • Будь проще. Возможно, не стоит делать функции на ровном месте.
      Ответить
    • 43 и 44 строки нужно поставить перед 41. Функция Parse_full_string() - самая говниная получилась (по множеству причин), хотя изначально планировал наоборот сделать код яснее. Определённо нужно переделать...
      Ответить
      • Попробуй написать всё без функций, чтобы увидеть алгоритм целиком. А потом уже подумай, что можно выделить в осмысленные функции с небольшим количеством аргументов. Я с подобных портянок на паскале и начинал.

        Сходу проектировать функции сложно если опыта нету.

        З.Ы. Если ты не можешь за одну короткую фразу сказать что делает функция или класс -- это неудачная абстракция, попробуй по-другому.
        Ответить
      • Разбиение портянки на функции делается для трёх вещей:
        1) Какую-то часть портянки хотелось бы использовать в другом алгоритме или проекте. Научиться подобно Шики видеть линии в коде так, чтобы переиспользовать его, можно тупо делая несколько проектов: рано или поздно встретится задача, которую ты уже где-то решил.
        Вообще, на переиспользуемости кода я бы не рекомендовал зацикливаться, по крайней мере на первое время. Код, который стóит переиспользовать, должен быть крайне хорошо реализованным, протестированным и документированным, и он должен быть универсальным. С этими пунктами даже создатели языков стандартных библиотек языков умудряются обосраться.
        2) Для упрощения чтения и понимания кода, чтобы составляющие части алгоритма были изолированы и именованы. Зачастую функция будет использоваться только один раз, и это нормально. В этом случае функция, во-первых, даёт имя какой-то части алгоритма, помогая читателю понять, что хотел сказать автор. И, во-вторых, ограничивает область видимости этой части алгоритма.
        Допустим, весь алгоритм целиком работает с 30 переменными. Если он написан одной портянкой, то для его понимания нужно постоянно удерживать в памяти состояние всех 30 переменных. Без лошадиных доз риталина (запрещён в РФ) это невозможно. Теперь разобьём его на вспомогательные функции. Допустим, в среднем такая функция на вход принимает 3 переменных и возвращает одну. То есть они работают с куда меньшим количеством информации, и ментальное усилие, необходимое для понимания каждой из них, становится посильным.
        1/2
        Ответить
        • 3) Ну и главное: юнит-тесты. Что это такое мне пересказывать лень, но приучаться их писать стоит с малых лет. Главное в этой дискуссии, что они также помогают правильно структурировать код. Если по совету из пункта 2 правильно разбить код на функции, то юнит-тесты будет легко писать и читать. Если разбиение на функции произошло неправильно, то писать тесты будет крайне сложно. В общем, рекомендую запилить их для твоего примера, чтобы разобраться с концепцией, и в дальнейшем всегда держать в памяти мысль: "а как я буду эту функцию авто-тестировать?"
          2/2
          Ответить
          • юнит-тесты помогают правильно структурировать код для написания юнит-тестов, лол

            сепульки
            Ответить
            • Неправильно выразился. Юнит-тесты помогают правильно структурировать код для чтения и понимания. Т.е. если код трудно читать, его, как правило, трудно и тестировать.
              Ответить
              • Конничива, CHayT.
                Ответить
              • вероятно, ты хотел сказать, что трудно отлаживать

                потому что юнит-тесты работают с блэкбоксом и на читаемость им в общем-то насрать
                Ответить
          • P.S. Кстати про автотесты. Их нужно учиться писать сразу, ибо никто кроме тебя их не сделает. Профессия QA стремительно отмирает. Я работал в трёх крупных конторах, которые можно было бы назвать не шарашкиными, и должность QA была только в одной. И то, она делала железки, и в ней QA занимались в основном ручным тестированием, типа выдернуть из работающей ноды кабель или блейд. В двух других юникорнах написание автотестов было целиком на совести программистов.
            Ответить
            • > Профессия QA стремительно отмирает.
              > Я работал в трёх крупных конторах и должность QA была только в одной
              - ошибка выжившего налицо, так сказать. Не надо работать в криптоцыганских стартапах
              Ответить
              • Да нет, там просто решили, что раз сам «Microsoft» разогнал своих тестеров — то чем они хуже?
                Ответить
                • И сразу багов меньше стало на доске, больше времени на разработку фич. А то тестят тут всякие...
                  Ответить
                • все мы немного майкрософт?
                  Ответить
                • Лол, при чём тут мелкософт. Сейчас в заднем конце всюду `CI/CD', которые слабо сочетается с ручным тестированием. А автоматическое property-based тестирование какой-нибудь middleware питушни один фиг требует глубокого знания протоколов и алгоритмов.
                  Ответить
                  • > Сейчас в заднем конце всюду `CI/CD', которые слабо сочетается с ручным тестированием.

                    - почему?
                    Ответить
                    • Потому что заебёшься каждый коммит тестировать. continuous же (ненавижу это слово, вечно u пропускаю).
                      Ответить
                      • ну ладно сборка, но зачем настраивать деливери на каждый коммит? может, дело не в CI/CD как таковом?)
                        Ответить
                        • Чтобы фичи до клиента быстрее доезжали! Пятилетку за полгода.
                          Ответить
                          • ещё быстрее они будут доезжать, если просто бросать в клиента сырцами, пусть сам билдит
                            Ответить
                        • деливери смотря куда
                          на прод можно не каждый коммит, а только тот, который отмечен правильным форматом тега
                          Ответить
                        • > ну ладно сборка, но зачем настраивать деливери на каждый коммит?

                          А почему, собственно, нет, если у тебя stateless мелкосервиc с гринблёй?
                          Ответить
                          • я подозреваю, что просто правильная фраза звучит как

                            stateless мелкосервиc слабо сочетается с ручным тестированием

                            в мобайле CI/CD никак не мешает мануальному тестированию и я не понимаю даже, как он может мешать-то
                            Ответить
                            • Ну если не каждый, а раз в неделю, когда мануальщики дотестируют, то это уже не CD. Не?
                              Ответить
                              • не понял тебя

                                ты настраиваешь CI/CD, чтобы при пуше в фича-ветку он делал билд, гонял тесты и выбрасывал артефакт или орал про ошибки красненьким

                                при мердже пул-реквеста CI/CD делает то же самое, только ещё заливает билд в систему дистрибуции, откуда его могут забрать тестировщики, попутно сря нужными комментариями в слак и джиру

                                почему раз в неделю?
                                Ответить
                                • Потому что тест-план у мануальщика на неделю и он физически не сможет тестировать каждый коммит? Ну т.е. это CI но не CD.

                                  Если у тебя там не тысяча китайцев в подвале, конечно.
                                  Ответить
                                  • тестировщику прилетает уведомление, что такой-то тикет перевёлся в Ready for QA. он идёт в тикет и читает номер билда в комментариях

                                    сливает себе билд с этим номером и тестирует

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

                                    ферштейн?
                                    Ответить
                                  • Это CD, потому что после окончания работ над конкретной задачей происходит деливери.
                                    Ответить
                                    • Блядь... так там ещё и оттенки continous delivery (CD) и continous deployment (тоже CD)... Первое действительно манулы могут доделывать. А второе -- это полная автоматика.
                                      Ответить
                                • То, что ты описал, концептопитуально не CI/CD. Если твой билд-пайплайн высерает артифакты, которые должны дополнительно пройти через ручной процесс, чтобы считаться годными, то это должно быть отражено в структуре репы путём дополнительных веток/тегов. Т.е. должны быть ветки типа "stable" и "integration" (названия могут быть другими, но суть одна) и разные типы артефактов. Иначе, твой тестировщик может найти багу в "stable", а баг-то уже в ней, и билд заказчику улетел.
                                  Т.е. в твоём процессе получается, что специально обученный человек прогоняет тесты на артефакте с "integration" и даёт добро на мердж в "stable", и заказчику попадает артифакт со "stable". И где здесь continuous, Desktop?
                                  Ответить
                                  • мне лень объяснять очевидные вещи, тем более, что в твоей конторе процессы видимо настроены по-другому

                                    что там концептуально или нет, мне похуй, мне надо деливерить фичи, а не с концепцией танцы танцевать
                                    Ответить
                        • Ситуация: у тебя есть коммит с багом, который проскользнул через тесты (автоматические, мануальные — один фиг). Ты деливеришься в прод и баг случается.
                          1) Ты заделиверил один мёрдж-коммит, и сразу понимаешь, что в нём баг. Откатываешь сервис на один коммит.
                          2) Ты разом заделиверил 30 фич, одна содержит баг, и две других меняют схему персистентных данных, и их нельзя откатить, ибо старый код сломается о новые данные.

                          Какой вариант выберешь?

                          CD не панацея, и есть ситуации, когда его использовать в принципе нельзя (например, если сервис очень stateful, и любой баг в нём может распидорафтить все данные). Но если его можно использовать, его стоит использовать.
                          Ответить
                          • мы говорим про разные вещи?

                            я не утверждаю, что CI/CD не нужен, я считаю, что он нужен

                            я говорю, что он не отменяет возможность ручного тестирования

                            деливерить можно не только лишь на прод
                            Ответить
                          • если ты знаешь в чем баг, то сделать 31ю фичу довольно несложно

                            если ты на прод заливаешь 30 фич, переинтегрированных между собой, то у тебя на это есть причины - очевидно, 30 фич осилились не за 30 спринтов, а за 1 (один, карл), т.е. скорее всего продукт молодой и активно запиливается

                            гораздо сложнее для молодого продукта тестировать каждый коммит, тормозя остальные 29, это дорого и зло - не важно кто будет тестировать этот коммит, твои тестеры, наемные тестеры, волонтеры или заказчик
                            Ответить
                            • > если ты знаешь в чем баг, то сделать 31ю фичу довольно несложно

                              Первая проблема: у тебя 30 коммитов, а не один. Нужно понять, в каком из них баг.

                              > если ты на прод заливаешь 30 фич, переинтегрированных между собой (не обязательно! прим. редактора), то у тебя на это есть причины - очевидно, 30 фич осилились не за 30 спринтов, а за 1 (один, карл), т.е. скорее всего продукт молодой и активно запиливается

                              ...Или старый, большой, и монолитный и его пилят 5 команд со своими спринтами.

                              > гораздо сложнее для молодого продукта тестировать каждый коммит

                              Больше инстансов дженкинса, больше параллельности тестов.
                              Ответить
                              • > Первая проблема: у тебя 30 коммитов, а не один. Нужно понять, в каком из них баг.
                                звучит как проблема на 10 минут, если честно

                                если ты смотришь в код и не понимаешь как так случилось, то даже зная в каком коммите проблема ты потратишь ~ столько же времени

                                потому что не исключено, что вскрытая проблема вообще не связана с этими коммитами, а живёт в проде уже пару месяцев

                                > Больше инстансов дженкинса, больше параллельности тестов.
                                заказчик должен параллельно 30 версий прода запускать в работу? а потом слать отчеты, что "вот у меня тут как-то не всё работало в 14:18 в среду"?
                                Ответить
                                • > если ты смотришь в код и не понимаешь как так случилось, то даже зная в каком коммите проблема ты потратишь ~ столько же времени

                                  Если у меня один коммит, и после его деплоя прилетает алярм, что количество 500х ошибок выросло на 1%, то я не смотрю в код. В принципе. Я откатываю деплой, и смотрю на логи и код потом в тихой и спокойной обстановке. Или кубернитис это сам делает, останавливает гринблю и меня пингует в ёбаном мессенджере на электроне. Смотреть в логи и код, пока прод подгорает, я тоже умею, но нахер мне такое удовольствие.
                                  Ответить
                                  • ну так что делать с тем, что за спринт у тебя 30 коммитов ты так и не сказал, хотя сам с этого и начал

                                    ошибка 500 это не единственный признак "ПО работает не так как мы ожидали" и даже близко не

                                    особенно в кейсе @Desktop, который деливерит мобильное приложение

                                    если что, я не оппонирую, мне наоборот интересно где можно (нужно) улучшить наши внутренние процессы
                                    Ответить
                                    • > ошибка 500 это не единственный признак "ПО работает не так как мы ожидали" и даже близко не

                                      Ну естественно. Но если исповедовать религию "let it crash", то это хорошая аппроксимация.
                                      Ответить
                                • > заказчик должен параллельно 30 версий прода запускать в работу? а потом слать отчеты, что "вот у меня тут как-то не всё работало в 14:18 в среду"?

                                  У заказчика есть только REST API. Нахер ты ему билды своих облачных микросервисов отдаёшь?
                                  Ответить
                                  • у заказчика информационная система, в которой есть пользовательские приложения (мобила, веб), бекенды/сервисы с базами, интеграционные взаимодействия, всё это делает один поставщик

                                    а ты "только рест апи"
                                    Ответить
                                    • С этим я не спорю (хотя текущая контора и в клиентских приложениях тоже умеет в подобие гринбли, когда новые фичи деливерятся в спящем виде, и по сигналу с C&C сервера постепенно подрубает их у некого кол-ва пользователей, начиная с сотрудников, потом перейдя к тем юзерам, кто жамкнул галочку "хочу участвовать в бета-тестах", и т.д.). просто тред начался с поста, который имеет следую фразу:

                                      > Сейчас в заднем конце всюду `CI/CD',

                                      (D as deployment)
                                      Ответить
                                      • бля, я не распарсил, что задний конец в данном контексте это продуктовый backend, подумал, что речь просто про дев-инфраструктуру

                                        xD
                                        Ответить
                                  • > Нахер ты ему билды своих облачных микросервисов отдаёшь?

                                    Ну видимо требования по персональным данным или ещё какой-нибудь секретности, что заказчик должен на своей инфраструктуре крутить.
                                    Ответить
                                    • > что заказчик должен на своей инфраструктуре крутить

                                      Ну так это совсем другая ситуация. Тут концептуально появляется понятие релиза, планирования релизов и т.д., и continous deployment улетает в трубу.
                                      Ответить
            • > P.S. Кстати про автотесты. Их нужно учиться писать сразу, ибо никто кроме тебя их не сделает.

              Как мне написать автотест, чтоб он проверял что вот такой-то код на сишке на таком-то STM32 говноконтроллере с такими-то эрратрами будет настраивать вот такой-то кодек (настраиваемый через через I2C шину и передающий-принимающий аудиосемплы в дуплексном решиме по шине I2S) и это будет нормально работать?
              Ответить
              • Заливаешь код на макетку, вторым контроллером принимаешь семплы и смотришь, что всё заебись.

                З.Ы. Ну или даже эхо-тест через перемыку, раз он и передаёт и принимает.
                Ответить
                • Не, ну можно специальную хуйню для автотестов собрать, только это лишнее. Написал код, хорошенько его оттестировал (на слух проверяешь, что звук не пердит и записывается нормально) и потом дальше не трогаешь его без надобности.
                  Автотесты ж нужны для какой-то часто меняющейся и хитрым образом переплетенной питушни, когда изменения хуйни1 может влиять на работу хуйни2 самым неочевидным образом.
                  Ответить
                  • > часто меняющейся и хитрым образом переплетенной питушни

                    Либо если сложная логика, все ветки которой заёбывает проходить вручную.
                    Ответить
                  • А так то да, я тоже против тестирования тривиальной хуйни.
                    Ответить
                    • > А так то да, я тоже против тестирования тривиальной хуйни.

                      Ничего вы не понимаете в комфорте. Свои пет-проекты, к примеру, я всегда пилю спросонья, либо усталым, и порой люблю их рефакторить, чтобы не воняли. Я бы в жизни не стал этого делать, если бы не был уверен, что если CI прошёл, то ничего тривиального не сломалось. Ну и руками что-то тестировать мне лень, не барское это дело.

                      Ну или по работе импелементацию какого-нибудь stateful асинхронного протокола с шестью версиями и десятком полей тоже попробуй руками протестируй. А так один раз написал property-based тестбед с инжекцией ошибок и течёшь. Вкалывают роботы, а не человек.
                      Ответить
                      • Я про всякие геттеры-сеттеры-конструкторы, которые так любят обмазывать автотестами джависты. Ну смысл на них писать тесты?
                        Ответить
                        • > джависты

                          Ну мы тут про людей говорили, вроде.
                          Ответить
                          • А так то да, проще тест хуйнуть чем передавать в функцию что-то руками.
                            Ответить
                  • А вообще такой макет для тестов может иметь смысл. Можно его погонять сутки-другие, посмотреть нет ли каких-то залипаний и потерь от других задач, которые на том же чипе крутятся. На слух ты заебёшься такой стресс-тест делать.

                    Ну если эта стабильность важна, конечно.
                    Ответить
                    • З.Ы. Я так ловил гонку в сетевой либе, которая возникала один раз за миллионы пакетов. Без макета так и не узнал бы, наверное.
                      Ответить
                    • > На слух ты заебёшься такой стресс-тест делать.

                      "10 hours of HEYYEYAAEYAAAEYAEYAA"
                      Ответить
              • Пришёл поручик j123123 и всё опошлил омикроконтроллерил.
                Ответить
              • Хотя теоретически можно написать эмулятор всей хуйни(вместе с эрратрами, лол), но тогда тебе еще надо автотесты на то, что ты правильно всю хуйню эмулируешь. В общем, жопа
                Ответить
                • Не, ну если просто от регрессов подстраховаться -- можно подсунуть простейший мок вместо реальных портов. И тогда хоть на прыщах хоть на винде этот тест гоняй. Будет уверенность, что он нужные регистры в правильном порядке заполняет. По крайней мере те же самые, что и год назад.
                  Ответить
              • Когда я над железкой (размером с холодильник) работал, для высокоуровневщены был эмулятор, а для низкоуровщены — лаба с порезанными версиями этой железки, где на один блейд вместо нормального софта ставился трафик-генератор, которой пинал другой блейд. Всё это бутстрапилось expect'ом через telnel по COM порту, лол. Ах, счастливые, незамутнённые кубернитисом времена.
                Ответить
                • > незамутнённые кубернитисом

                  Кубернетис против реального железа -- это как надувная тян против подушки.
                  Ответить
                  • А что лучше?
                    Ответить
                  • что это за нахрюк на виртуалки?

                    они вполне себе виртуаляца уже, вон я недавно про single root I/O virtualization читал: писи ай экс пресс умеет реально вротуализировать тебе несколько сетевых карт (виртуальных функций)
                    Ответить
                    • А виртуалки тут причем?
                      Ответить
                      • не причем, k8s же про контейнеры с докером
                        Ответить
                        • уже ксстати не с докером, а напрямую с containerd или чотам
                          Ответить
                          • Или выпей шампанского, какой нахуй докер?
                            Ответить
                          • Образá докера там пока остались.
                            Ответить
                            • > образа докера

                              И лики сишного аллокатора?
                              Ответить
                              • кстати, о докерах

                                Знаете, что такое безысходность?

                                Это когда берешь стабильную слаку, а докера там нет.
                                Ставишь slackbuildы со всеми сорока зависимостями, но поставив go, забываешь перечитать профайл, и в PATH у тебя вместо go -- gcc-go, и сборка докера падает от отсутствия понимания параметра buildmode.

                                Потом ты всё таки ее собираешь, и ставишь docker-compose (собрав еще 10 зависимостей), но он 2018-го года, и не понимает Compose Specification.

                                Ты пишешь автору слак билда "could u please upgrade хуё-мое", и получаешь ответ от мейлер демона, что такого мыла нет.
                                Ответить
                                • От концовки что-то аж хрюкнул.
                                  Ответить
                                • Пора бы уже закопать стюардессу...
                                  Ответить
                                  • да, я наверное перейду на дебиан или на убунту в будущем году.

                                    Каждый месяц кто-то пишет на LQ "а вы видели ченджлог каррента? кажется, скоро у нас будет 15!"

                                    Каждый месяц последние три года.

                                    Но самое смешное, что докера в карренте нет. И нгинкса нет. И постгри. И node.

                                    Зато есть PHP, Apache и squid. Всё хочу спросить у Патрика как ему там в 2006-м?
                                    Ответить
                                    • > кажется, скоро у нас будет 15

                                      Скоро у нас будет 15 лет без релиза?
                                      Ответить
                                      • Slackware 15, ну. С новейшим (на момент 1 января 2015-го года) софтом. И ядром..
                                        Ответить
                                • > could u please upgrade

                                  Да проще из генты ебилд спиздить, чем разрабам писать...

                                  Серверный софт всё-таки не десктоп, достаточно чтобы ядро да либцы прокатили.
                                  Ответить
                                  • > чтобы ядро да либцы прокатили

                                    Если ты каждую прогу с её зависимостями в отдельный каталог в /opt'е складываешь, конечно. Стандартную помоечку в /lib заебёшься поддерживать если ты не Патрик.
                                    Ответить
                                    • слакбилды сами все складывают, а sbopkg даже умеет их скачать и собрать

                                      но зависимости нужно хендлить вручню: к примеру поставить слакбилд с go, чтобы собрать им слакбилд с докером
                                      Ответить
                                      • > но зависимости нужно хендлить вручню

                                        В этом и проблема. Невозможно адекватно мейнтейнить стандартную юниксовую помоечку самому. У тебя нет времени и ресурсов на сведение версий либ к общему знаменателю, тестирование совместимости и т.п. Сам же пишешь, что часть слакбилдов морально устарела и не поддерживается. Да и мартышкин труд, т.к. в других дистрах всё это уже сделано за тебя.

                                        Установка каждой программы (программы в смысле "продукта", а не "бинарника") в отдельный каталог вместес нужными ей либами позволяет снизить интерференцию между софтом и хоть как-то выжить. По сути docker way без докера. Я когда-то слаку так и админил.
                                        Ответить
                                        • Невозможно, именно потому Патрик и залип.
                                          Пока в Слаке было три пакета в 1997-м году, он справлялся, а современный юникс требует сотен программ и либ, и можно крянкуть.

                                          Я правда не понял, чем отдельные папки лучше slackbuilds.
                                          Авторы слакбилдов гарантируют тебе совместимость с версией дистра (хочется так думать).

                                          Слакбилды так же умеют себя удалять.

                                          Если ставить в каждую папку вручную, то придется потом ldconfigу рассказывать про либы, не?

                                          Но вообще проще всё запускать в докере, и течь.

                                          Кстати, идею зависимостей породили бздуны.
                                          Сначала у них был только тот софт, что шел в комплекте с ОС (ну как в слаке), но потом они завезли порты с зависимостями, и стало можно поставить софт, которого в стандартной поставке нет, и не ебаться с его зависимостями
                                          Ответить
                                          • > чем отдельные папки лучше slackbuilds

                                            Это ортогональные вещи. Я против установки самосборного говна в /lib. А слакбилды норм, если их подтюнить немного и сменить префикс.

                                            > придется потом ldconfigу рассказывать про либы

                                            Ни в коем случае. Убьёшь весь профит от изоляции.
                                            Ответить
                                            • вручную что-то ставить в либ, а потом вручную это удалять или обновлять это просто путь в ад, примерно как врунчую удалять установленный софт с винды вычищая все его регистрации классов в реестре.

                                              >ни в коем случае
                                              а, так ты за то, чтобы вручную в petuh1 и petuh2 поставить нужную им версию libkurochka?

                                              когда я устанавливаю софт методом аутоконф configure make make install, то конечно я его ставлю в /usr/local/petuhsoftname
                                              Ответить
                                              • Да хоть вручную хоть пакетами... Я в принципе против сранья в общий /lib если ты не мейнтейнер дистриба. Ибо это адовый гемор и риски при обновлении софта.

                                                Я за сборку каждой софтины (postgres, nginx и т.п.) со своим независимым префиксом. Ну и все либы, которые им нужны -- прям к ним в этот же префикс. В худшем случае LD_LIBRARY_PATH в ланчере придётся добавить.

                                                Это та же самая идея, что сейчас во всяких virtualenv и докерах исповедуется.

                                                А упаковать этот каталог в tgz и ставить через пакетник никто не мешает. В случае слаки тут ещё один профит -- получается ОДИН пакет без зависимостей.
                                                Ответить
                                                • тогда на кой хуй мне вообще дистрибутив?

                                                  пусть там будет голое ядро, и каждый софт в своем докер контейнере... как в корос
                                                  Ответить
                                                  • > пусть там будет голое ядро, и каждый софт в своем докер контейнере

                                                    А оно к тому и идёт, походу. На серваках везде докер. На десктопах шаттлврот свой snap пропихивает. На телефонах тоже всё изолировано.

                                                    Дальше поддерживать /lib -- это тупиковый путь, имхо. Это было круто и удобно в своё время, но сейчас от этого одни проблемы.
                                                    Ответить
                                                    • Ну да, это было круто, когда место стоило дорого, а контейнеров не было.

                                                      Да и админкам нравилось обновить либу и "пофиксить" сразу кучу софта.

                                                      Забавно, что первыми адовость этого говна осознайли майки со своим "dll hell", когда пользователя спрашивали хуйню

                                                      Еще Чен смеялся над вопросами установщика типа "вы хотите заменить petuh.dll 2.2.3.3 версией 2.2.3.4?".

                                                      Замени, и молись, чтобы ничего не упало нигде.

                                                      Прыщевикам было чуть проще, потому что весь софт ставился из единой дырки.

                                                      Майки завезли SxS еще двадцать лет назад, просто мало кто пользовался

                                                      Ну вот и остальных это конснулось
                                                      Ответить
                                                      • > потому что весь софт ставился из единой дырки

                                                        Угу. Ну и security фиксы обычно минимальные и ничего не ломают, поэтому минорное обновление либы таки прокатывает.

                                                        А вот какую-то фичу, нужную свежему софту, ты будешь ждать полгода до следующего релиза. Или пять, лол, если ты сторонник стабильности.
                                                        Ответить
                                                        • ну да, на дебиане вроде python3.7, например.

                                                          но можно сказать, что использование только системного говна дает тебе стабильность. Если я хочу например собирать SNMP с железок и выводить результаты в каком нить MRTG, то мне в общем всё равно какая у меня версия nginx.

                                                          А если я буду врунчую запускать докер контейнеры, то вынужден буду не забывать их обновлять бо security, и еще настраивать
                                                          Ответить
                                                          • > не забывать их обновлять

                                                            Ну есть же софт, который мониторит версии говна в контейнерах и предупреждает про уязвимости в нём.

                                                            > дает тебе стабильность

                                                            И отбирает гибкость, заставляя тебя выбирать между "всё стабильное" и "всё свежее". Хотя, по-хорошему, тебе надо всего пару свежих прог, а остальное могло бы быть стабильным.
                                                            Ответить
                                                            • Софт есть, но apt тоже не плохо работает, и он проще:)

                                                              Вообще я бы сказал, что есть три разные задачи:

                                                              * Сервер приложений, версии софта на котором выбирает РАЗРАБОТЧИК

                                                              * Сервер сервисов сети или просто сетевой инфраструктуры, софт на котором выбирает АДМИН

                                                              * Рабочая машина ПОЛЬЗОВАТЕЛЯ

                                                              Все три сценарии могут требовать разного.

                                                              Docker однозначно лучше для первого, и какой-то SNAP для третьего. А вот для второго возможно что ничего этого не нужно
                                                              Ответить
                                                              • > apt тоже не плохо работает

                                                                До первого случая, когда тебе понадобится свежий софт. А потом Сёма себе роутер убивает по советам с форумов, лол.
                                                                Ответить
                                                                • так вот для кейса "2" он не понадобится

                                                                  ну админы же как-то живут с тем, что для поддержки нового RFC нужно менять версию винды, или там ios, и их это не смущает.

                                                                  Вот если админ скажет разрабу "мы не можем перейти на новую версию питона, потому что ее нет в дистрибе" это пиздец, лулз, зашквар, и PHP4 на шаред хостинге.
                                                                  Ответить
                                                                  • > так вот для кейса "2" он не понадобится

                                                                    Не знаю, если честно. Может быть в 2020 году и не понадобится. Для стандартных задач, где можно просто стандартную коробку в духе циски купить и течь.
                                                                    Ответить
                                                                    • для маршрутизации и свитчинга угу, но я говорил о мониторинге сети, или еще о какой-нить параше типа почтового сервера или openldap..
                                                                      Ответить
                                                                      • > почтового сервера

                                                                        Ну не. Прикрутят очередную хуйню, без которой твои письма пойдут в спам, и весь сервак обновлять?

                                                                        openldap и какая-нибудь файлопомойка с самбой -- ну х.з., наверное.

                                                                        А хрень для мониторинга -- отличный кандидат для запуска в контейнере. Тогда её можно будет обновлять реже чем сам сервак.
                                                                        Ответить
                                                                        • тогда уж скорее самба протухнет, и будет не уметь последнюю версию винды:)

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

                                                                          А с докером что? Мне или докер компост писать, или делать фет контейнер вручную?
                                                                          Ответить
                                                                          • Готового докерфайла со всей этой требухой никто не выложил что ли?

                                                                            > фет контейнер

                                                                            Как что-то плохое. Ты вон вообще в систему проги ставишь ;)
                                                                            Ответить
                                                                            • >готового докер файла
                                                                              Так это и будет фэт.

                                                                              >как что-то плохое

                                                                              Ну по какой-то причине за это ругают. Я как-то в одном проекте запустил django, cron и gunicorn в одном контейнере, так на меня девопсы до сих пор пальцем показывают.

                                                                              Алсо, фэт контейнеры должны иметь init (pid 1) процесс по идее, иначе могут быть зомби. Наражаешь детей, да помрешь. А кто их похоронит?
                                                                              Ответить
                                                                              • > Ну по какой-то причине за это ругают.

                                                                                goto тоже ругают... Но между установкой говна в систему и фет контейнером выбор по-моему очевиден.

                                                                                З.Ы. Я думаю, за установку джанги без контейнера эти девопсы тебя вообще бы обоссали.
                                                                                Ответить
                                                                                • на хабре был какой-то кейс, когда чувак стейт машину написал на goto, и получилось охуенно. Просто вот есть диаграмма на бумажке в стандарте, и по ней код, и всё понятно:)

                                                                                  В моем случае вариант с системой и не канал, кстати: мы деплоились докерфайлом на aws. Там конечно можно вручную всё положить на VPS, но AWS может её в любой момент убить
                                                                                  Ответить
                                                                              • Если есть выбор из компоста (и его аналоги в к8с) и фэт, надо брать компост.

                                                                                А для адекватного контроля детей мы однажды сделали контейнер, где фореграунд процесс был системд, лол. Но насколько я помню, там уже было как раз проще поебаться с системд, чем нагородить большую помойку не совсем классических контейнеризуемых сервисов
                                                                                Ответить
                                                                                • у aws есть свой сорт компоста (task definition или как-то так), мерзкий jsonовый файл.

                                                                                  Наш фет был продиктован выбором крона.

                                                                                  Допустим, твой сервис должен каждую минуту нести яйцо.

                                                                                  Если он писан например на жаве или net, то он работает постоянно, и можно (например библиотекой quartz) это красиво решить.

                                                                                  Если же ты скриптушок, то красивое решение это API. А в соседнем контейнере хертбит сервис, который каждую минуту дергает API.

                                                                                  Можно это всё обмазать celery или другим каким-то queue, и потечь.

                                                                                  Но это всё слишком сложно для тупого приложения.

                                                                                  Потому мы сделали как PHPшники: крон сервис, который дерагет наш скрипт раз в минуту.

                                                                                  В джанге даже есть удобный API для этого: пишешь функции, расставляешь аннотации типа "звать раз в час", главное снаружи чтобы кто-то точку входа дергал по крону
                                                                                  Ответить
                                                                                  • Питон же тоже умеет персистентные процессы, как и жаба.

                                                                                    У меня паук на ngk через uwsgi мулов крутился, никаких кронов там не было.

                                                                                    Да и просто так контейнер с долгоиграющим скриптом можно поднять...
                                                                                    Ответить
                                                                                    • так а где поднять то, если мы говорим про тонкие контейнеры?

                                                                                      ну вот есть кнтейнер с джангой, там нужно дергать python manage.py итд

                                                                                      Хотя возможно увизги бы нам помог
                                                                                      Ответить
                                                                                • > А для адекватного контроля детей мы однажды сделали контейнер, где фореграунд процесс был системд, лол.

                                                                                  Больные ублюдки. Чем supervisord не подошёл? (Ну или любой другой легковесный супервизор, тысячи их)
                                                                                  Ответить
                                                                                  • Мы в докере поднимали системд, который поднимал иксы, в которых поднималась DE, в которой запускается оболочка, которая запускает браузер.

                                                                                    Думаешь, супервизорд подойдёт?
                                                                                    Ответить
                                                                                    • > Мы в докере поднимали системд, который поднимал иксы, в которых поднималась DE, в которой запускается оболочка, которая запускает браузер.

                                                                                      Какой микросервис )))
                                                                                      Ответить
                                                                                      • Хотели возможность обновки всего этого бутерброда удаленно и контролируемо. Кстати именно тогда выяснили, что убунта кор поебень, надо в снапстор свое ПО хуй знает как публиковать и приватного снапстора нихуя нет. Так что докер.

                                                                                        Девайс стартует без хостовых иксов, докер делает всё остальное.
                                                                                        Ответить
                                                                                        • Вариант поднять свою репу и тупо обновлять своё приложение apt'ом с неё не рассматривали? Мы с CentOSю (RIP) такое делали, зависимость есть.
                                                                                          Ответить
                                                                                          • Рассматривали, но докер это охуенно. Он не только этот сервис поднимал. И надо понимать, что физически девайс не наша собственность. Поэтому репа это хрупко и не так атомарно.
                                                                                            Ответить
                                                                                            • > но докер это охуенно.

                                                                                              В составе k8s может ещё да, а вот голый Dockerd с компостом держать на долгоживущих хостах — такое. Мне несколько раз приходилось чистить вилкой /var на старых дев-хостах с ним, ибо долгоносик^W докер в нём пожрал всё место под логи или какую-то другую питушню.
                                                                                              Ответить
                                                                                              • Потому что дев-хосты. Там одной командой старые ненужные образы можно вычистить, ее в крон.

                                                                                                Но да, все когда-либо сталкиваются в первый раз с этим.

                                                                                                О, ништяк, команда стала ещё проще
                                                                                                docker system prune
                                                                                                Ответить
                                                                                                • Но есть один нюанс: она не очень хорошо работает, когда /var полностью забит логами, лол. Докер перехватывает stdout и хранит его в своих директориях, чтобы docker log работал. Если дев-хост ставил ротоёб, не настроивший ротацию логов, это фиксить довольно муторно.
                                                                                                  Ответить
                                                                                                  • Ротоеб должен был включить голову и настроить срать логи в системный журнал.

                                                                                                    Кстати, в центос 7 есть редкая бага в systemd-journald, которая при активном наполнении логов тупо мемличит. Журналд может и десяток Гб рам нажрать таким образом
                                                                                                    Ответить
                                                                                                    • Если я правильно понял диспозицию, то на девмашине типа под CI раннеры, когда десятки билдов и коротких ранов, ротация ненастроенных логов не поможет, т.к. логи тупо внутри каждого конкретного контейнера в файлах лежат. Контейнер сдох, его никто не чистит, логи занимают место, как и слои. Ротация это удел долгоживущих контейнеров, и вот для них журналд как бе уместнее
                                                                                                      Ответить
                                                                                                      • Нет, на дев-машине именно долгоживущая питушня была для перемалывания статистики, нужной для дебага.
                                                                                                        Ответить
                                                                                          • aptom на центос? серьезно?:)
                                                                                            Ответить
                                                                                            • Блин, включи контекстное восприятие. D++ говорил про снап, из-за чего я решил, что они базируются на убунте. На CentOS yum. Грешновато как-то такое разжёвывать.
                                                                                              Ответить
                                                                                              • кстати, на centos уже dnf. Жаль, что centos уже не нужна.

                                                                                                ты прав, я наверное зря доебался
                                                                                                Ответить
                                                      • > место стоило дорого

                                                        Дык можно как в SxS расшаривать и трафик и место и память если так вышло, что двум прогам нужны одинаковые либы. Если более-менее одинаковые версии либ во все пакеты пихать, то норм будет. Что-то отстанет, что-то обгонит, но в среднем будет шариться.
                                                        Ответить
                                                        • в каком-то смысле так работает докер.

                                                          Если у меня два Dockerfile импортируют одного родителя, то он один качается, а потом они оверлапятся на него вроде
                                                          Ответить
                                                          • Ну кстати да. Они и в памяти поди расшарятся, раз с одного места на диске взяты.
                                                            Ответить
                                                            • наверное да, ведь их читают ммапя их в память, и если страничка из файла считана в RAM, и замаплена как R или X для одного питуха, то можно же сунуть ее в таблицу страниц и другому питуху
                                                              Ответить
                                  • >Да проще из генты ебилд спиздить, чем разрабам писать...

                                    docker-compose, ты не повериш, скачивается прямо отсюда:

                                    https://github.com/docker/compose/releases/download/1.27.4/docker-compose-Linux-x86_64

                                    это вот прямо эльф, со всем говном статически линкованный, и зависящий только от ядреных вызовов

                                    Это же go:)
                                    :~$ ldd docker-compose-Linux-x86_64
                                            linux-vdso.so.1 (0x00007fff93df2000)
                                            libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6cdc97c000)
                                            libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f6cdc960000)
                                            libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6cdc76e000)
                                            /lib64/ld-linux-x86-64.so.2 (0x00007f6cdc98d000)


                                    но я же хотел красиво
                                    Ответить
                                • Прочитал этот пост под gy!be, отлично подошло.
                                  Ответить
        • Добавлю, что иногда портянка читается лучше, чем насильно разбитый на функции код (см. код ОПа, который приходится в уме обратно инлайнить, или пример из чистого кода, который мы тут весь вечер пытались разобрать)...

          Граница между функциями должна проходить в логичных, простых местах, чтобы каждую из них можно было в отдельности рассмотреть и понять, не подглядывая в код соседних. А не просто потому что 10 строк или 30 переменных набралось.
          Ответить
          • > насильно разбитый на функции код

            Кстати да. Парсинг какого-то одного символа - более мелкая операция, которая входит в состав парсинга всей строки.

            Соответственно, читатель ожидает, что
            1. Parse_the_first_symbol парсит один символ, а Parse_full_string - целую строку,
            2. Parse_the_first_symbol будет какой-то вспомогательной функцией в составе Parse_full_string.

            А в коде автор даёт читателю ложную информацию и усложняет чтение кода. Разбиение на функции становится только обузой: чтобы разобраться в одной функции, приходится читать почти весь код, что эквивалентно чтению кода, если бы он весь был в одной функции.
            Ответить
            • через двадцать лет этот код засадит автора за решётку за насилие

              bad code matters
              Ответить
            • Да, я тоже долго не мог понять где начало. Ну и эта божественная функция с десятком аргументов, которая все виды сканирования покрывает... Я ее в уме инлайнил в точки вызова.
              Ответить
        • > Научиться подобно Шики видеть линии в коде
          А если в них ткнуть курсором — код развалится?
          Ответить
          • Кто тут вчера отрицал виабушность? Спалился.
            Ответить
            • Описание гуглится же по первой ссылке...
              Ответить
            • У меня просто широкий кругозор.
              Ответить
              • > широкий кругозор

                Разработанный кругозор.
                Ответить

    Добавить комментарий