Потому что docker будет следить за здоровьем процесса супервизора, а не вашего приложения, которое внутри ушло в вечный ребут. Такой контейнер будет здоровым, но бесполезным.
Ещё одна - особенность работы CFS. Когда количество потоков меньше лимитов, то могут быть ложные провалы хелсчеков. Например тому процессу, который обрабатывает хелсчек, просто не дали времени.
Собственно, вы правы. Изначально GraphQL был придуман в Facebook, чтобы меньше зависеть от бэкенда. Там же куча сервсов, а к каждому и не один запрос - вот и придумали гейтвей, на который можно было бы переложить эту сложность.
Обычно (кол-во слов) / (средняя скорость чтения). Например, про эту статью Хабр пишет 8 минут, но я проглядел и открыл интересные вкладки меньше, чем за минуту.
Простите, но вот выучит человек flask на базе своего pet-проекта и что? Его доля для прода падает с каждым днём. Почему бы не вложиться в тот же Django и показывать проект на собеседованиях?
Порог входа во Flask лишь в самом начале простой, подключение к бд уже проблема - приходится ещё 2 либы тащить. Что хуже - дальше встаёт вопрос какую из библиотек брать для тех же форм или API. В Django же есть как правило один официально рекомендуемый способ сделать что-то. Да, для прода не всегда подходящий, но новичку это знать и не надо.
Ну и про легковесность... Когда вы соберёте весь зоопарк, то не факт, что размер будет меньше.
Рекрутеры, может, и не откроют, но это отличная отправная точка для разговора. За 5-10 минут у любого проекта находятся места, о которых можно поговорить. Так что перед собеседованием я ставил DnD на 10 минут, чтобы успеть сделать чай и ознакомиться с резюме.
История с wsgi повторяется... может, и до pep на asgi договорятся.
Я так понимаю, что прод у вас в контейнерах. А почему бы тогда не запускать один процесс на контейнер и следить именно за ним? 12factor app предлагает делать именно так. Да и CFS будет понятнее работать.
Альтернативный вариант - переписать хелсчек таким образом, чтобы он проверял наличие процессов в поле.
Но это, конечно, как быстрое решение. Молодцы, что обновляетесь.
Пааагадите-ка, но решений для feature-toggle минимум десяток только популярных. Прежде чем пилить своё вы их конечно же сравнили? Ведь сравнили, правда? Была бы интересна статья именно на эту тему.
Омг, как только слона не насилуют, а он всё равно работает. А где сравнение с остальными решениями?
Открывая статью, я надеялся, что вы свой pluggable storage реализовали и горизонтальное масштабирование. Потому как от кеша требуется всё-таки AP, а не ACID, под который Postgres заточен очень сильно.
А зачем декомпилить? Можно ж включить дамп сертификатов и Wireshark посмотреть трафик. Это ж локально происходит, насколько я понимаю. Но anyway, это не задача курса. Если кто-то сможет такое провернуть, то автоматически достоен зачёта.
Ну, декомпиляцией я ещё на первом курсе занимался, когда крякмишки ломал. SoftICE, IDAPro... В данном случае должно быть не сильно сложно, т.к. строки для проверки вставляются в секцию .data и лежат как plain text.
Мои студенты сдают зачёт на отдельной купленной VPS. Я там создал кучу пользователей с паролями, собственно, сам её и админю. Так что могу позволить себе собрать образ и позволить запускать его из make. Лично мне так проще - оверхеда ноль и полная переносимость (т.е. тестирую я локально).
К тому же докеру посвящена примерно треть курса: от "что это такое" до cgroups/namespaces/layerfs, так что на одном из занятий планирую чтобы они сами с помощью dive раскопали как происходит проверка. Может, успею пасхалку какую на самозачёт положить, чтобы воспитать дух хакерства :)
Задумка очень хорошая и, главное, кстати! Но воспользоваться, увы, не смогу. Опишу основные мои претензии как преподавателя, читающего курс по администрированию Linux в местном универе.
Самое интересное - task_checker, так что начал с него. Слегка удивлён, что там сишный код. Ожидал увидеть что-то более высокоуровневое, но да ладно... Во-первых, тест-кейсы задаются прямо в .h файлах - хотелось бы более декларативного описания заданий. Во-вторых, опциональный экспорт в LMS в этом же каталоге - мне кажется, что это всё-таки отдельная сущность. В-третьих, ИМХО, проверка должна быть не интерактивная - проверять сразу всё; не нашёл - проблема студента.
В моём понимании чекер должен быть каким-то docker-образом, куда монтируется каталог студента и проверяются захардкоженные файлы. Я думал сделать на pytest - там можно легко перехватывать stdout и сравнивать с ожиданием. Правда, в моей специфике чекер будет ещё проверять ФИО студента, наличие ssh-ключа и проверку shellcheck.
То ли Крок, то ли ещё кто из интеграторов делился историей, что им надо было прокатить работающую стойку через весь коридор за время работы аккумуляторов. Благо для сети кабели были подлинее.
Потому что docker будет следить за здоровьем процесса супервизора, а не вашего приложения, которое внутри ушло в вечный ребут. Такой контейнер будет здоровым, но бесполезным.
Ещё одна - особенность работы CFS. Когда количество потоков меньше лимитов, то могут быть ложные провалы хелсчеков. Например тому процессу, который обрабатывает хелсчек, просто не дали времени.
Каждый день к девяти мне надо идти в магистрат... Не скажу, что это подвиг, но вообще что-то героическое в этом есть...
Имя аккаунта говорящее. Вот только тут даже сторис самого Хабра особо не прижились.
Вот да. А ещё одновременно делать небольшие фиксы, раскидывая их по разным листам изменений (changelist).
Пример с молоком показательный, что все врут (c) В описании 950г, а цена 99.90 за кг, а итоговая не пересчиталась. Но покупатель же не заметит...
Собственно, вы правы. Изначально GraphQL был придуман в Facebook, чтобы меньше зависеть от бэкенда. Там же куча сервсов, а к каждому и не один запрос - вот и придумали гейтвей, на который можно было бы переложить эту сложность.
Вы так акцентируетесь на IPv6, можете подсказать почему?
Обычно (кол-во слов) / (средняя скорость чтения). Например, про эту статью Хабр пишет 8 минут, но я проглядел и открыл интересные вкладки меньше, чем за минуту.
Простите, но вот выучит человек flask на базе своего pet-проекта и что? Его доля для прода падает с каждым днём. Почему бы не вложиться в тот же Django и показывать проект на собеседованиях?
Порог входа во Flask лишь в самом начале простой, подключение к бд уже проблема - приходится ещё 2 либы тащить. Что хуже - дальше встаёт вопрос какую из библиотек брать для тех же форм или API. В Django же есть как правило один официально рекомендуемый способ сделать что-то. Да, для прода не всегда подходящий, но новичку это знать и не надо.
Ну и про легковесность... Когда вы соберёте весь зоопарк, то не факт, что размер будет меньше.
Рекрутеры, может, и не откроют, но это отличная отправная точка для разговора. За 5-10 минут у любого проекта находятся места, о которых можно поговорить. Так что перед собеседованием я ставил DnD на 10 минут, чтобы успеть сделать чай и ознакомиться с резюме.
История с wsgi повторяется... может, и до pep на asgi договорятся.
Я так понимаю, что прод у вас в контейнерах. А почему бы тогда не запускать один процесс на контейнер и следить именно за ним? 12factor app предлагает делать именно так. Да и CFS будет понятнее работать.
Альтернативный вариант - переписать хелсчек таким образом, чтобы он проверял наличие процессов в поле.
Но это, конечно, как быстрое решение. Молодцы, что обновляетесь.
Как модемы всю ночь трещали, отдавая за битом биты...
Соль бывает не только поваренная.
Пааагадите-ка, но решений для feature-toggle минимум десяток только популярных. Прежде чем пилить своё вы их конечно же сравнили? Ведь сравнили, правда? Была бы интересна статья именно на эту тему.
Омг, как только слона не насилуют, а он всё равно работает. А где сравнение с остальными решениями?
Открывая статью, я надеялся, что вы свой pluggable storage реализовали и горизонтальное масштабирование. Потому как от кеша требуется всё-таки AP, а не ACID, под который Postgres заточен очень сильно.
А зачем декомпилить? Можно ж включить дамп сертификатов и Wireshark посмотреть трафик. Это ж локально происходит, насколько я понимаю. Но anyway, это не задача курса. Если кто-то сможет такое провернуть, то автоматически достоен зачёта.
Ну, декомпиляцией я ещё на первом курсе занимался, когда крякмишки ломал. SoftICE, IDAPro... В данном случае должно быть не сильно сложно, т.к. строки для проверки вставляются в секцию .data и лежат как plain text.
Мои студенты сдают зачёт на отдельной купленной VPS. Я там создал кучу пользователей с паролями, собственно, сам её и админю. Так что могу позволить себе собрать образ и позволить запускать его из make. Лично мне так проще - оверхеда ноль и полная переносимость (т.е. тестирую я локально).
К тому же докеру посвящена примерно треть курса: от "что это такое" до cgroups/namespaces/layerfs, так что на одном из занятий планирую чтобы они сами с помощью dive раскопали как происходит проверка. Может, успею пасхалку какую на самозачёт положить, чтобы воспитать дух хакерства :)
Задумка очень хорошая и, главное, кстати! Но воспользоваться, увы, не смогу. Опишу основные мои претензии как преподавателя, читающего курс по администрированию Linux в местном универе.
Самое интересное - task_checker, так что начал с него. Слегка удивлён, что там сишный код. Ожидал увидеть что-то более высокоуровневое, но да ладно... Во-первых, тест-кейсы задаются прямо в .h файлах - хотелось бы более декларативного описания заданий. Во-вторых, опциональный экспорт в LMS в этом же каталоге - мне кажется, что это всё-таки отдельная сущность. В-третьих, ИМХО, проверка должна быть не интерактивная - проверять сразу всё; не нашёл - проблема студента.
В моём понимании чекер должен быть каким-то docker-образом, куда монтируется каталог студента и проверяются захардкоженные файлы. Я думал сделать на pytest - там можно легко перехватывать stdout и сравнивать с ожиданием. Правда, в моей специфике чекер будет ещё проверять ФИО студента, наличие ssh-ключа и проверку shellcheck.
То ли Крок, то ли ещё кто из интеграторов делился историей, что им надо было прокатить работающую стойку через весь коридор за время работы аккумуляторов. Благо для сети кабели были подлинее.