И для чего работать с болванчиком, которой кроме как матом орать ничего не может? Что-бы раз за разом разрушать свою психику? Что-бы в итоге выгореть?
Если начальник не может что-то спокойно донести или убедить без перехода на мат и личности - фигня полная ваш начальник.
"Прогибающее поведение" это то, когда работнику нужно рефлексировать над поступками и последствиями? А руководителю нужно искать подход к работнику и уметь отстаивать свою позицию не выходя за рамки принятого в индустрии поведения?
Ну тогда да, давайте не будем прогибать работников, лучше будем ломать их об колено! Главное что-бы они ещё и не поняли за что.
Потому что данные и логику смешивать вредно. - В случае когда бизнес-логика выносится из сервисного слоя приложения, то начинается её многократное дублирование.
- Так-же такую логику тяжелее поддерживать и расширять.
- В разныех БД по разному пишутся хранимки и по разному оптимизируются. Это значит, что в случае миграции с PostgreSQL ну например на Oracle будет большая боль в процессе переноса этой логики. В случае когда вся логика находится внутри приложения, то придётся просто переключить драйвер и может поправить миграции, которые идут в обход ORM.
- В рамках одной БД от версии к версии может поменяться фнкциональный набор для написания хранимок. Например что-то что было deprecated - уберут. И такое изменение не позволит осуществить переезд.
- Одним из существенных минусов использования хранимых процедур - это значительные трудности поддержания версий кода.
- Масштабирование приложений со сложной логикой - проще и дешевле чем масштабирование бд
- Логика в приложении гораждо проще поддаётся качественному тестированию
На самом деле - это очень холиварная тема. Если вы знаете что делаете и для чего, то возможно хранимки вам подойдут. С другой стороны, хорошей архитектуры у приложения добиться скорее всего будет очень сложно, а зависимось от базы будет очень жёсткой.
Вот есть пост тут от 2014 года где активно холиварят. Вот пост тут от 2020 статья в более пессимистичном духе к хранимкам
Посмотрите, почитайте, а там ужа сами решайте, нужно вам это или нет
К сожлению, цианоакрилата и соды порой недостаточно. Например на моём опыте есть ноутбуки, где посадочные места рассыпались в прах, а петлям ни wd-шка ни что-либо другое не помогало и они продолжали выламывать крепления. В таких случаях действительно помогает только сквозное крепление.
P.S. прибегаю к этому методу только если сломаны крепления в подставке,а не в крышке. ну и если новая подставка дороже ноутбука
Никак не показано кто и как будет будет заполнять папку с файлами для обработки, а между прочим логика скрипта-менеджера, который бы распределял нагрузку на доступные машины, была бы куда интереснее.
Судя по коду, к получению файлов вы никогда не перейдёте.
While True:
Time.sleep(60)
#Получаем список файлов
files = os.listdir(directory)
если это псевдо-код, то он несёт краёне малое количество полезной нагрузки.
А если линукс, то как быть или в системе может не быть мейлера, тогда как?
Как вариант - можно посмотреть в сторону Geany который обладает широким функционалом, выглядит так-же как notepad и при том собран под Linux, Windows, MacOS
В отличии от sshto, которое выглядит действительно хорошо, куб-диалог выглядит очень неповоротливым. Например: - Менять пространствои имён на лету? - Фильтрация? - Сортировка? - Поиск? - Возможность одновременного редактирования/просмотра/ подключения любой сущности?
если есть жгучее желание комфортно управлять оркестратором из консоли, то обычные комманды в коммандной строке предоставят больше возможностей
В случае одного или двух, край пяти - такое сработает. Но когда речь заходит за десятки и при том не часто используемые, то через год-два в голове останутся хорошо еси обрывки.
#Загрузка образа из сети docker pull docker/compose:1.29.2
#Сохранение образа локально docker save -o docker_compose_1.29.2.tar docker/compose:1.29.2
#Загрузка образа с локального диска docker load < docker_compose_1.29.2.tar
Дальше останется только выкачивать npm, pip... и т.д. репозитории, пакеты для OC, саму OC и тогда данные точно никуда не пропадут.. пока жив жёсткий диск)
А на уровне железа это и вовсе по одним каналам работает. Вот только для создания и обработки HTTP запроса потребуется кратно больше ресурсов и времени. Так как сокет инициализирует соединение, а потом засылает небольшие пакеты данных. В то время как каждый HTTP запрос ,будет слать всё тело с кучей всевозможной информации.
Ваш подход вполне будет работать, пока не появятся некоторые "если": - Плохое соединени (например в сети кто-то качает торрент, а роутер слаб) - Слабый сервер (запуск игры съест все ресурсы и обработка HTTP запросов станет дольше)
В таких случаях задержка от нажатия на "геймпаде" до нажатия в системе будет занимать секунды.
казус в том, что если машина будет спасать водителя ценой жизни общества, то общество не допустит такие машины на дороги, а если машина будет спасать общество ценой жизни водителя, то такую машину никто не захочет покупать
Отнюдь, я совершенно не строгий судья и часто могу почитать статьи которые могут быть скомканными или размазанными, одним словом разные. Но зачастую, во всех статьях, есть суть которая тянется красной нитью через всё повествование и к концу максимально раскрывается, в вашей-же истории вы решили её прервать и вместо кульминации ввернули развязку. Вместо катарсиса получается фрустрация.
Поэтому если хотите писать историю своего пути, то стоит сделать это максимально красиво. - Посмотрите на основные правила построения сценария - Разбейте сюжет на главы или на части - Заранее обозначте колличество глав
История оставляет от себя чувство недосказанности. Есть завязка, есть конфликт, но нет его разрешения. Не очень понятно с какими трудностями вы столкнулись дальше, какие технолигии пришлось освоить, какие проекты удались, а какие нет и в чём заключались сложность и риски.
По итогу, совершенно не ясен путь, который вы прошли, так как описано самое начало.
А как «фишинг» уйдёт, если создать реплику сайта с похожим доменом? в такой атаке нет необходимости во взаимодействии с оригинальными клиент / сервер. останется вопрос как туда траффик нагнать, но это уже другая история
Остальные зелёные источники энергии ни могут предоставить стабильную и контролируемую энергию. Это конечно отчасти решается БОЛЬШИМ колличеством батарей для хранения энергии что по итогу так-же выльется в огромные захоронения батарей
В итоге, для удовлетворения рынка электро-транспорта будут в большинстве использоваться те-же классические электростанции. вот только учитывая их КПД и потери при транспортировке энергии до электродвигателя в вашей машине, общее кпд будет значительно меньше чем при использовани двс.
А если учесть ещё и то, что современный двс снабжён катализаторами и системами повторного использования отработанных газов, (а это то чего нет на элекстростанциях) то экологичность электротранспорта встаёт под большой вопрос.
вот только от аэс и гэс отказываются из-за той-же экологии
газ или водород в огромном танкере звучит настолько взрывоопасно, что в случае аварии, любой порт быстро станет как в Бейруте. электрические установки такой мощности в обозримом будующем не смогут долго работать с текущим уровнем развития батарей. а экстримальных условиях так и вовсе атомные реакторы применяют, причём не просто так.
4. Кузов, салон, силовые и прочие узлы разберут. но вот стоимость извлечения драг материалов из батареи непомерно высока на текущий момен, а эффективность наоборот. к тому-же занимается такой деятельностью на так уж и много предприятий. (чёт вот покрышки массово складируют во всём мире, а они по проще батарей будут, да и появились сильно задолго)
так что да, в ближайший цикл выхода из эксплюатации батарей, мы будем наблюдать миллиарды литиевых батарей на свалках в странах третьего мира
И для чего работать с болванчиком, которой кроме как матом орать ничего не может?
Что-бы раз за разом разрушать свою психику? Что-бы в итоге выгореть?
Если начальник не может что-то спокойно донести или убедить без перехода на мат и личности - фигня полная ваш начальник.
"Прогибающее поведение" это то, когда работнику нужно рефлексировать над поступками и последствиями? А руководителю нужно искать подход к работнику и уметь отстаивать свою позицию не выходя за рамки принятого в индустрии поведения?
Ну тогда да, давайте не будем прогибать работников, лучше будем ломать их об колено!
Главное что-бы они ещё и не поняли за что.
Потому что данные и логику смешивать вредно.
- В случае когда бизнес-логика выносится из сервисного слоя приложения, то начинается её многократное дублирование.
- Так-же такую логику тяжелее поддерживать и расширять.
- В разныех БД по разному пишутся хранимки и по разному оптимизируются. Это значит, что в случае миграции с PostgreSQL ну например на Oracle будет большая боль в процессе переноса этой логики. В случае когда вся логика находится внутри приложения, то придётся просто переключить драйвер и может поправить миграции, которые идут в обход ORM.
- В рамках одной БД от версии к версии может поменяться фнкциональный набор для написания хранимок. Например что-то что было deprecated - уберут. И такое изменение не позволит осуществить переезд.
- Одним из существенных минусов использования хранимых процедур - это значительные трудности поддержания версий кода.
- Масштабирование приложений со сложной логикой - проще и дешевле чем масштабирование бд
- Логика в приложении гораждо проще поддаётся качественному тестированию
На самом деле - это очень холиварная тема.
Если вы знаете что делаете и для чего, то возможно хранимки вам подойдут. С другой стороны, хорошей архитектуры у приложения добиться скорее всего будет очень сложно, а зависимось от базы будет очень жёсткой.
Вот есть пост тут от 2014 года где активно холиварят.
Вот пост тут от 2020 статья в более пессимистичном духе к хранимкам
Посмотрите, почитайте, а там ужа сами решайте, нужно вам это или нет
Прям всю-всю нельзя положить в бд.
Но можно боложить большие куски логики в хранимки.
Правда это жёсткий антипаттерн. Ибо база не должна знать про бизнес логику приложений,
а приложение не должно быть завязано на какую-то конкретную бд.
К сожлению, цианоакрилата и соды порой недостаточно.
Например на моём опыте есть ноутбуки, где посадочные места рассыпались в прах, а петлям ни wd-шка ни что-либо другое не помогало и они продолжали выламывать крепления.
В таких случаях действительно помогает только сквозное крепление.
P.S. прибегаю к этому методу только если сломаны крепления в подставке,а не в крышке.
ну и если новая подставка дороже ноутбука
Никак не показано кто и как будет будет заполнять папку с файлами для обработки, а между прочим логика скрипта-менеджера, который бы распределял нагрузку на доступные машины, была бы куда интереснее.
Судя по коду, к получению файлов вы никогда не перейдёте.
если это псевдо-код, то он несёт краёне малое количество полезной нагрузки.
А если линукс, то как быть или в системе может не быть мейлера, тогда как?
Может данный скрипт и закрывает ваши личные потребности, но это всё довольно легко ищется в поиске.
Как вариант - можно посмотреть в сторону Geany который обладает широким функционалом, выглядит так-же как notepad и при том собран под Linux, Windows, MacOS
Ozon "Дозиметр Мастер-1" 5215р
компактен и работает от обычных батареек
В отличии от sshto, которое выглядит действительно хорошо, куб-диалог выглядит очень неповоротливым.
Например:
- Менять пространствои имён на лету?
- Фильтрация?
- Сортировка?
- Поиск?
- Возможность одновременного редактирования/просмотра/ подключения любой сущности?
если есть жгучее желание комфортно управлять оркестратором из консоли, то обычные комманды в коммандной строке предоставят больше возможностей
Для управления любым колличеством kubernetes оркестраторов, есть прекрасная утилита Lens
В случае одного или двух, край пяти - такое сработает.
Но когда речь заходит за десятки и при том не часто используемые, то через год-два в голове останутся хорошо еси обрывки.
Однако ничего не мешает сделать так:
#Загрузка образа из сети
docker pull docker/compose:1.29.2
#Сохранение образа локально
docker save -o docker_compose_1.29.2.tar docker/compose:1.29.2
#Загрузка образа с локального диска
docker load < docker_compose_1.29.2.tar
Дальше останется только выкачивать npm, pip... и т.д. репозитории, пакеты для OC, саму OC и тогда данные точно никуда не пропадут.. пока жив жёсткий диск)
А на уровне железа это и вовсе по одним каналам работает. Вот только для создания и обработки HTTP запроса потребуется кратно больше ресурсов и времени.
Так как сокет инициализирует соединение, а потом засылает небольшие пакеты данных. В то время как каждый HTTP запрос ,будет слать всё тело с кучей всевозможной информации.
Ваш подход вполне будет работать, пока не появятся некоторые "если":
- Плохое соединени (например в сети кто-то качает торрент, а роутер слаб)
- Слабый сервер (запуск игры съест все ресурсы и обработка HTTP запросов станет дольше)
В таких случаях задержка от нажатия на "геймпаде" до нажатия в системе будет занимать секунды.
казус в том, что если машина будет спасать водителя ценой жизни общества, то общество не допустит такие машины на дороги, а если машина будет спасать общество ценой жизни водителя, то такую машину никто не захочет покупать
Отнюдь, я совершенно не строгий судья и часто могу почитать статьи которые могут быть скомканными или размазанными, одним словом разные.
Но зачастую, во всех статьях, есть суть которая тянется красной нитью через всё повествование и к концу максимально раскрывается, в вашей-же истории вы решили её прервать и вместо кульминации ввернули развязку. Вместо катарсиса получается фрустрация.
Поэтому если хотите писать историю своего пути, то стоит сделать это максимально красиво.
- Посмотрите на основные правила построения сценария
- Разбейте сюжет на главы или на части
- Заранее обозначте колличество глав
История оставляет от себя чувство недосказанности.
Есть завязка, есть конфликт, но нет его разрешения.
Не очень понятно с какими трудностями вы столкнулись дальше, какие технолигии пришлось освоить, какие проекты удались, а какие нет и в чём заключались сложность и риски.
По итогу, совершенно не ясен путь, который вы прошли, так как описано самое начало.
А как «фишинг» уйдёт, если создать реплику сайта с похожим доменом?
в такой атаке нет необходимости во взаимодействии с оригинальными клиент / сервер.
останется вопрос как туда траффик нагнать, но это уже другая история
И всё-таки есть конкретные примеры:
Этот код в питоне вернёт None
re.match(r'\'(.*)+\'', "@test('hello')")в то время как на regex101.com в режиме Python - Match вполне находится
Match 16-13'hello'Что имеем на текущий момент -
1. Плановый отказ от АЭС
2. ГЭС несут огромный урон для экологии и поэтому учёные призывают к отказу от них
Остальные зелёные источники энергии ни могут предоставить стабильную и контролируемую энергию.
Это конечно отчасти решается БОЛЬШИМ колличеством батарей для хранения энергии
что по итогу так-же выльется в огромные захоронения батарей
В итоге, для удовлетворения рынка электро-транспорта будут в большинстве использоваться те-же классические электростанции. вот только учитывая их КПД и потери при транспортировке энергии до электродвигателя в вашей машине, общее кпд будет значительно меньше чем при использовани двс.
А если учесть ещё и то, что современный двс снабжён катализаторами и системами повторного использования отработанных газов, (а это то чего нет на элекстростанциях) то экологичность электротранспорта встаёт под большой вопрос.
вот только от аэс и гэс отказываются из-за той-же экологии
газ или водород в огромном танкере звучит настолько взрывоопасно, что в случае аварии, любой порт быстро станет как в Бейруте. электрические установки такой мощности в обозримом будующем не смогут долго работать с текущим уровнем развития батарей. а экстримальных условиях так и вовсе атомные реакторы применяют, причём не просто так.
4. Кузов, салон, силовые и прочие узлы разберут. но вот стоимость извлечения драг материалов из батареи непомерно высока на текущий момен, а эффективность наоборот. к тому-же занимается такой деятельностью на так уж и много предприятий.
(чёт вот покрышки массово складируют во всём мире, а они по проще батарей будут, да и появились сильно задолго)
так что да, в ближайший цикл выхода из эксплюатации батарей, мы будем наблюдать миллиарды литиевых батарей на свалках в странах третьего мира
Пожалуй стоит указать, что это выдержка из книги «Идеальный программист. Как стать профессионалом разработки ПО»
Интересная книга которая повествует о становлении программиста ненавязчивым слогом