Ваш вопрос завёл меня в некоторый тупик. Видите ли, вот всём. И когда на серьёзных щах такой вопрос задают -- зреют встречные вопросы
Однако mode собака-подозревака: off. Неужели всё описанное проще, чем:
Запуск контейнеров через docker compose run --rm --service_ports? Смысл в том, что:
Мы получаем интерактивную консоль, в которой без бубнов работает pdb
Время запуска / остановки контейнера на глаз не отличается от локального запуска процесса
Если вас пугает длинная команда и большое число аргументов -- вы же программист, не? Я алиасы в своё время создал в проекте, скрыв кучу аргументов и подковёрной дичи (если не знаете, докеры на разных платформах имеют свои нюансы), и с автодополнениями по табу
Для remote pdb / rdb пробрасываем изнутри наружу одинаковые порты. Тогда они даже команду правильную пишут -- копипастим не включая мозг
Описанное выше нахожу на порядок более простым и идентичным локальному запуску, со всеми преимуществами локального запуска и при этом всеми преимуществами докера
Обратите внимание -- мой подход уместил в один комментарий -- настолько всё просто
Преимущественно на КГ/АМ. Однако есть и интересные замечания. Жаль, что их меньше, чем хотелось бы
Уровень статьи автор задаёт в примере №1 -- с козырей заходит, так сказать. Нормальные IDE покажут кириллицу -- оно сразу будет заметно. WEB-интерфейс хабра эту разницу не показывает. Единственный вывод -- КГ/АМ
Но, ещё раз отмечу, в прочих примерах есть интересные нюансы -- за них спасибо
Если этот уровень -- весь ваш прогресс с 1997 года -- вы впали в анабиоз?
Мимо выпускник БГУИР. Кстати, шарага шарагой, бездарно потерянное время.
Мало того, что технический уровень -- просто испанский стыд (для первача норм), так отдельный испанский стыд, что это всё, чего вы достигли с 1997 года
Лоховство -- это неспособность понять свои цели. Даркнет -- это просто инструмент, который можно комбинировать с любым другим инструментом. Нет ничего плохого, что сайт в даркнете минимизирует собственный трафик и использует AJAX или Websocket.
Я пытался дать ответ такой, чтобы мамкины скрипт-кидди не бросились ломать всё, но и люди в теме поняли, где слабое место. Максимум, что могу добавить -- в данном случае атакующее ПО не соответствует спецификации 802.11, но это не его проблемы
Самое банальное -- разделить render на renderWait, renderReady, renderEmpty и renderError. Скорее всего, что-то из этого вам достаточно реализовать единожды.
Мне для моего пет-проекта для навигации в гетерогенной иерархической структуре требовалось реализовать несколько типов branch-node и leaf-node. Причём, естественно, поведение всех бранчей одинаково -- возможность дозапроса вложенных нод. Тут без множественного наследования вообще никак
Обобрямс. У меня также есть глупые вопросы "сколько раз исполняется код" к функциональным компонентам (ответ -- на каждый рендер создаются новые замыкания. А потом разводим руками на вопрос, почему всё так тормозит). Переиспользуемость же реализует ООП. Да, в JS плохо с множественным наследованием, что вынуждает заниматься инкостыляцией, но жить можно.
Очень сложно проводить аналогии между ORM для Питона и плюсов
Аналогии -- интересный нюанс. Если вы про воспроизведение аналогичного API -- то это идея гиблая и ненужная. Я предлагаю смотреть, как решения устроены под капотом, и по мере необходимости эти решения в подходящем виде переносить себе. По сути я предлагаю обратить внимание на компилятор запросов, на предлагаемые клиентские подходы (см. bindparam), на кэшируемость объектов запросов, и так далее -- на низкоуровневые нюансы. На рефлексию, наконец -- это уберфича концепции ORM
Поэтому, в оригинальном qt не получится перенести генерацию кода запросов на этап компиляции.
Это не нужно. Нигде так не делают, это абсурдно. При необходимости подключиться вместо мускуля к постгресу вы на серьёзных щах предлагаете перекомпилировать клиентское приложение? Вместо этого сделайте такое API, чтобы объекты запросов (ВНИМАНИЕ -- это не только строки, это ещё и метаданые, во имя рефлексии) можно было кэшировать. Ни одно реальное приложение не обладает неограниченным списком запросов к БД, а CGI в далёком прошлом, чтобы переживать за единичное проседание производительности на первом запросе
А по поводу вашей задачи, я не очень понял, в чём, собсно, проблема
Кстати вообще не поняли. Как тестировать работу REPL? Как тестировать поведение REPL с учётом отправки команд и анализа результата? Как протестировать, не сломался ли REPL? Сейчас приходит понимание, что похожий с этой точки зрения инструмент уже есть, только он о другом и вообще из другого мира -- это selenium. Естественно, он не подходит для моей задачи. Значит, всё же надо городить огород с expect и его аналогами типа pexpect. И начинать с написания фреймворка для тестирования поведения терминала. Блин, оно мне надо?
Наработки интересные и однозначно заслуживают внимания. За ORM я бы порекомендовал поизучать принципы работы ORM на других языках. Я сам питонщик, и у нас напитоне много всяких разных ORM: от попсовой DjangoORM (однозадачная хр%нь) до гибкой SQLAlchemy (которая меня очень порадовала гибкой и расширяемой поддержкой SQL)
Да, в данном случае согласен. Java не динамический язык -- и тут сюрпризов не будет. Сюрпризы пораждает сам джуновский подход -- и я вижу как раз одно подходящее место в другом запросе. А вообще мне любопытно пощупать, как оно работает
Ваш вопрос завёл меня в некоторый тупик. Видите ли, вот всём. И когда на серьёзных щах такой вопрос задают -- зреют встречные вопросы
Однако
mode собака-подозревака: off. Неужели всё описанное проще, чем:Запуск контейнеров через
docker compose run --rm --service_ports? Смысл в том, что:Мы получаем интерактивную консоль, в которой без бубнов работает
pdbВремя запуска / остановки контейнера на глаз не отличается от локального запуска процесса
Если вас пугает длинная команда и большое число аргументов -- вы же программист, не? Я алиасы в своё время создал в проекте, скрыв кучу аргументов и подковёрной дичи (если не знаете, докеры на разных платформах имеют свои нюансы), и с автодополнениями по табу
Для remote pdb / rdb пробрасываем изнутри наружу одинаковые порты. Тогда они даже команду правильную пишут -- копипастим не включая мозг
Описанное выше нахожу на порядок более простым и идентичным локальному запуску, со всеми преимуществами локального запуска и при этом всеми преимуществами докера
Обратите внимание -- мой подход уместил в один комментарий -- настолько всё просто
На одном из прошлых проектов я такое видел. ИМХО подход остро конфликтует с принципом KISS и характеризуется ключевым словом `overcomplicated`
Однако допускаю, что приму этот вариант со временем
Шмотри -- и правда подсвечивает
Преимущественно на КГ/АМ. Однако есть и интересные замечания. Жаль, что их меньше, чем хотелось бы
Уровень статьи автор задаёт в примере №1 -- с козырей заходит, так сказать. Нормальные IDE покажут кириллицу -- оно сразу будет заметно. WEB-интерфейс хабра эту разницу не показывает. Единственный вывод -- КГ/АМ
Но, ещё раз отмечу, в прочих примерах есть интересные нюансы -- за них спасибо
Интересно, что в своих ранних статьях вы называли вещи правильно
Рейтинг статьи соответствует её уровню -- низкий. Карму не слили -- и на том хорошо
Спасибо за статью!
Автор. При собеседовании на уровень Junior требуется знать разницу между потоками и корутинами. Ты её не понимаешь.
Если этот уровень -- весь ваш прогресс с 1997 года -- вы впали в анабиоз?
Мимо выпускник БГУИР. Кстати, шарага шарагой, бездарно потерянное время.
Мало того, что технический уровень -- просто испанский стыд (для первача норм), так отдельный испанский стыд, что это всё, чего вы достигли с 1997 года
Лоховство -- это неспособность понять свои цели. Даркнет -- это просто инструмент, который можно комбинировать с любым другим инструментом. Нет ничего плохого, что сайт в даркнете минимизирует собственный трафик и использует AJAX или Websocket.
Не могли бы вы объяснить, каких попугаев меряет бенчмарк по оси Y? От дополнительной информации касательно оси X тоже не откажусь
То есть я зря пытался не сказать лишнего. Ладушки :)
Я пытался дать ответ такой, чтобы мамкины скрипт-кидди не бросились ломать всё, но и люди в теме поняли, где слабое место. Максимум, что могу добавить -- в данном случае атакующее ПО не соответствует спецификации 802.11, но это не его проблемы
man aircrack-ngА если серьёзно, то достаточно немного подумать нестандартно. А чём проблема с помощью
airbase-ngсоздать honeypot?Самое банальное -- разделить
renderнаrenderWait,renderReady,renderEmptyиrenderError. Скорее всего, что-то из этого вам достаточно реализовать единожды.Мне для моего пет-проекта для навигации в гетерогенной иерархической структуре требовалось реализовать несколько типов branch-node и leaf-node. Причём, естественно, поведение всех бранчей одинаково -- возможность дозапроса вложенных нод. Тут без множественного наследования вообще никак
Обобрямс. У меня также есть глупые вопросы "сколько раз исполняется код" к функциональным компонентам (ответ -- на каждый рендер создаются новые замыкания. А потом разводим руками на вопрос, почему всё так тормозит). Переиспользуемость же реализует ООП. Да, в JS плохо с множественным наследованием, что вынуждает заниматься инкостыляцией, но жить можно.
К сожалению, фронт-энд эволюционирует не во имя здравого смысла, а во имя моды. И мой первый камень летит в хуки
Очень внимательно читаем. Сути всё равно не уловили.
Аналогии -- интересный нюанс. Если вы про воспроизведение аналогичного API -- то это идея гиблая и ненужная. Я предлагаю смотреть, как решения устроены под капотом, и по мере необходимости эти решения в подходящем виде переносить себе. По сути я предлагаю обратить внимание на компилятор запросов, на предлагаемые клиентские подходы (см. bindparam), на кэшируемость объектов запросов, и так далее -- на низкоуровневые нюансы. На рефлексию, наконец -- это уберфича концепции ORM
Это не нужно. Нигде так не делают, это абсурдно. При необходимости подключиться вместо мускуля к постгресу вы на серьёзных щах предлагаете перекомпилировать клиентское приложение? Вместо этого сделайте такое API, чтобы объекты запросов (ВНИМАНИЕ -- это не только строки, это ещё и метаданые, во имя рефлексии) можно было кэшировать. Ни одно реальное приложение не обладает неограниченным списком запросов к БД, а CGI в далёком прошлом, чтобы переживать за единичное проседание производительности на первом запросе
Кстати вообще не поняли. Как тестировать работу REPL? Как тестировать поведение REPL с учётом отправки команд и анализа результата? Как протестировать, не сломался ли REPL? Сейчас приходит понимание, что похожий с этой точки зрения инструмент уже есть, только он о другом и вообще из другого мира -- это selenium. Естественно, он не подходит для моей задачи. Значит, всё же надо городить огород с expect и его аналогами типа pexpect. И начинать с написания фреймворка для тестирования поведения терминала. Блин, оно мне надо?
Наработки интересные и однозначно заслуживают внимания. За ORM я бы порекомендовал поизучать принципы работы ORM на других языках. Я сам питонщик, и у нас напитоне много всяких разных ORM: от попсовой DjangoORM (однозадачная хр%нь) до гибкой SQLAlchemy (которая меня очень порадовала гибкой и расширяемой поддержкой SQL)
И касательно "без счастливого конца" -- недавно сам грустил -- не знаю, как тестировать написанный код
Да, в данном случае согласен. Java не динамический язык -- и тут сюрпризов не будет. Сюрпризы пораждает сам джуновский подход -- и я вижу как раз одно подходящее место в другом запросе. А вообще мне любопытно пощупать, как оно работает