Так-то оно так, но вот ситуация, когда из-за сети сделаной «чтоб подешевле», или дешёвой железки («зачем тебе такой коммутатор? есть попроще и дешевле») встают продажи (производственный процесс) и как в итоге — недополученная прибыль или вообще убытки. Тогда как? Понятно, что перегибать не стоит, но это касается и тех и других.
Может и сделано, но 10 минут назад про него и не знал :) Но тогда, было принято решение дописать костыль (оный благополучно трудится уже лет 5), в несколько десятков строк кода, к тому, что уже есть, нежели городить очередной комбайн сбоку.
Это да, проблема но не фатальная. Случился в моей жизни переезд, кардинальный такой: со сменой города, работы — с тех. директора до простого сисадмина (а по сути эникейщика, да и эта должность далась с трудом), с понижением зп в два раза. Опыта жалко, знаний жалко, а что делать? Когда надоело сидеть и себя жалеть теряя драгоценное время — взялся за питон =) вдруг пригодится когда.
Отправил резюме на вакансию админа, за 10 дней 16 просмотров резюме на hh! Неужель настолько интересное резюме, что прочтение каждый раз приносит что-то новое? :) (на всякий случай замечу — я без претензий, просто интересно)
Да, я про getopt в курсе, и для тикля есть подобные, просто в данном случае для 2-3 опций использование дополнительного пакета счёл не целесообразным :)
Склеивать строку запроса из ключей вместе со значениями не очень хорошая идея. В вашем случае SQL инъекции можно не бояться, но если вдруг на входе прилетит лишняя запятая или кавычка, то запрос сломается и вы об этом даже не узнаете.
Тут набор данных строго регламентирован, лишнего не прилетит, если только не ошибки с порта.
Лучше использовать параметры SQL запроса:
В моём случае подойдёт вариант со списками, спасибо за подсказку. Как я понял данный код:
q_key_list = ", ".join([str(k) for k in q_keys])
Мы перебираем список «for k in q_keys» и из его элементов преобразованных в строку «str(k)» лепим опять же строку с разделителем ", ".
Поскольку у вас CentOS 7, можно просто добавить systemd unit и получить две последние плюшки практически безвозмездно
К примеру, динамическое построение интерфейса и работа с оным (генерация формы ввода данных в БД, как вариант) на tcl/tk делается куда как проще и изщьнее нежели на pyqt (хотя не исключаю, что не до конца «расковырял» эту связку).
И выравнивания и отступы это все есть. Хотя, надо признать, что «голый» Tk выглядит… аскетично (в винде он выглядит как любое другое приложение), но тотже BWidget, вполне себе настраивается. На мой взгляд, по скорости и удобству разработки небольших переносимых графических приложений, мало что может поспорить со связкой tcl/tk (надеюсь поклонники python и Qt меня сейчас не запинают :) ).
С позволения автора, вспомнил ещё один подобный продукт — Visual Tcl, проект вполне живой и рабочий (только что проверил). Т.е. если кому нужно для ознакомления с Tcl/Tk, то вполне подойдет http://vtcl.sourceforge.net
tutorial — учебное пособие, учебник, руководство, инструкция
Да, я про getopt в курсе, и для тикля есть подобные, просто в данном случае для 2-3 опций использование дополнительного пакета счёл не целесообразным :)
Тут набор данных строго регламентирован, лишнего не прилетит, если только не ошибки с порта.
В моём случае подойдёт вариант со списками, спасибо за подсказку. Как я понял данный код:
Мы перебираем список «for k in q_keys» и из его элементов преобразованных в строку «str(k)» лепим опять же строку с разделителем ", ".
Так и сделано, сервис запускается через systemd.
Спасибо за комментарий!
Я когда начинал изучать tcl перепробовал массу всяких программ, в итоге запили свою ide и пользуюсь по сей день (правда редко уже).