import re
separator = re.compile('\s+')
with open("access.log") as log_file:
for line in log_file:
parts = re.split(separator, line)
if parts[8] == '500':
print(line)
Работа с базой
import psycopg2
conn = psycopg2.connect(dbname='database', user='db_user', password='mypassword', host='localhost')
cursor = conn.cursor()
cursor.execute('SELECT deal_city_id, "ShortName", "FullName" FROM public.deal_city ORDER BY deal_city_id')
for row in cursor:
print(f"{row['deal_city_id']} {row['ShortName']} {row['FullName']}")
cursor.close()
conn.close()
А я в статье и не призываю никого учить Perl и ничего против питона не имею
Я просто счёл нужным оставить этот коммент на тот случай, если статью будет читать кто-то, кто пока не ориентируется в языках, но присматривает подходящий инструмент автоматизации )
Можете считать это глубоким имхо, но я должен это написать:
сейчас рекомендовать Perl в качестве скриптового языка в сфере системного администрирования стоит только тем, кто уже знает Perl, и почему-то принципиально против изучения питона
рекомендовать Go в качестве скриптового языка в сфере системного администрирования стоит только тем, кто в своих специфических задачах упирается в производительность, и не может найти подходящего модуля для питона
всем остальным 99,9% системных администраторов всё-таки стоит взять питон
Очень зависит от специфики конкретного сервиса.
Если возникает необходимость независимо масштабировать части систему — монолит в пролёте.
Если возникает необходимость независимо выкатывать части системы — монолит в пролёте.
Ну а единая БД может быть и при микросервисной структуре (правда, многие считают это анти-паттерном).
А если понадобиться не просто изменить константу, а поменять саму логику?
Например, бизнес скажет, что теперь заказ истекает через семь дней только в тех случаях, если в момент его создания луна была в четвёртом доме.
И такие изменения могут происходить многократно. Поверьте мне, вы не захотите каждый раз менять это в дюжине разных мест.
Это вы хотите дальше поспорить, у меня такого намерения вообще не было.
Ещё раз повторяю: коллег со стороны бизнеса мы не отфутболивали. Мы обрисовали им как будет себя вести этот показатель на разных бизнес-кейсах, и спросили — точно ли они хотят именно этого. После чего коллеги взяли тайм-аут на подумать, и больше к этому вопросу уже сами не возвращались.
Речь шла про то, что бизнес просто механически комбинируя концепции "средний чек" и "показатель в разрезе отделения" придумали химерический показатель, который не демонстрирует ничего реального. А наш ИТ-директор вместо того, чтобы взять и тупо реализовать имеющееся ТЗ как оно есть, потратил своё время, чтобы подробно показать бизнесу, как этот показатель будет себя вести в разных бизнес-кейсах.
После чего бизнес сам понял, что такой показатель им не нужен.
PS: Если что — минус вам поставил не я, у меня нет возможности голосовать за комментарии.
Не, вы не поняли суть предложения.
Если ИИ использовать только для построения запроса, а потом этот запрос запускать по базе, то никаких выдуманных данных в выдачу не может попасть.
Тут проблема в другом — это будет работать только для простых и типовых ситуаций. В любых нетипичных ситуациях чтобы только правильно сформулировать задачу, человеку нужно будет ясно понимать структуру данных в базе и механику построения запроса к БД. И если человеку всё равно приходится вникать в такие тонкости, то ему и сам запрос удобнее и надёжнее будет описать на точном и формальном языке БД, а не на человеческом языке.
Обычный человек обычными словами говорит:
«Мне нужен список клиентов, по которым не было продаж в этом году, но раньше были»
И для простых селектов это будет отлично работать. Для более сложных — только если человек хорошо представляет себе структуру данных в базе и нюансы построения запросов.
Я несколько лет назад работал в сети медицинских центров. И от бизнеса пришёл запрос реализовать построение отчёта в котором будет такая вещь как «средний чек по отделению». На все просьбы уточнить, что имеется в виду, бизнес отвечал: «Ну вы же знаете, что такое средний чек? Вот просто сделайте его в разрезе отделений». Заказчик сердился, что мы не понимаем такой простой вещи и тянем с выполнением задачи.
В итоге ИТ-директор усадил коммерческого директора за стол, обрисовал ему несколько типовых и краевых кейсов, и спросил — вот конкретно в этих ситуациях что именно вы ожидаете от «среднего чека в разрезе по отделениям». Коммерческий директор сказал, что он это обдумает и ответит чуть позже.
И больше с этой темой к нам никто не приходил.
И ведь до этого бизнес был истово уверен, что понимает, что конкретно он хочет.
А если бы с этим они обратились к нейросети, и она им какой-то отчёт по такому запросу построила бы? И люди бы потом по данным этого отчёта принимали бы какие-то управленческие решения.
Ну ок, вы взяли небольшие куски кода, и сравнили производительность по ним.
Но можно ли масштабировать эти выводы на картину в целом?
Если код написан ясно, то при необходимости изменить его, разработчик с большей вероятностью увидит более изящный и оптимальный способ сделать это.
Если же код написан запутанно, то с большей вероятностью разработчик будет править фрагмент кода без понимания того, как он взаимодействует с остальным кодом. И в итоге код будет представлять из себя лоскутное одеяло, где каждый лоскуток может работать очень быстро, но в итоге программа "почему-то" будет тормозной и забагованной.
Основная причина медленной работы ПО — халатность и рукожопие, а вовсе не следование каким-либо практикам.
Использовать методологию ХХИВП можно на любом языке.
Питон только даёт возможность разрабатывать быстрее и проще, за что его ценят в том числе и последователи ХХИВП, но далеко не они одни.
А то, что оно потом разваливаться начнёт
Если нормально писать, то ничего не начнёт разваливаться. На любом языке можно писать плохо. И если питон за счёт низкого порога входа популярен среди слабых программистов, никак не свидетельствует о том, что питон сам по себе плох.
Бэкенд бэкенду рознь.
Если на нём вам нужно выполнять какую-то развесистую бизнес-логику, и нет совсем уж жёстких требований по производительности, то питон — лучшее, что вы можете выбрать в данном случае.
Но, конечно, если вам на бэкенде какую-то суровую числодробилку надо реализовать, то питон действительно брать не стоит.
Вот так получается на питоне:
Хорошая мысль, я займусь этим в выходные.
Я просто счёл нужным оставить этот коммент на тот случай, если статью будет читать кто-то, кто пока не ориентируется в языках, но присматривает подходящий инструмент автоматизации )
Можете считать это глубоким имхо, но я должен это написать:
Я про САП ничего не знаю :(
Можете объяснить на пальцах, как можно в монолите независимо масштабировать/деплоить части системы?
Очень зависит от специфики конкретного сервиса.
Если возникает необходимость независимо масштабировать части систему — монолит в пролёте.
Если возникает необходимость независимо выкатывать части системы — монолит в пролёте.
Ну а единая БД может быть и при микросервисной структуре (правда, многие считают это анти-паттерном).
Чтобы натыкались только намеренно? )
А если понадобиться не просто изменить константу, а поменять саму логику?
Например, бизнес скажет, что теперь заказ истекает через семь дней только в тех случаях, если в момент его создания луна была в четвёртом доме.
И такие изменения могут происходить многократно. Поверьте мне, вы не захотите каждый раз менять это в дюжине разных мест.
Это вы хотите дальше поспорить, у меня такого намерения вообще не было.
Ещё раз повторяю: коллег со стороны бизнеса мы не отфутболивали. Мы обрисовали им как будет себя вести этот показатель на разных бизнес-кейсах, и спросили — точно ли они хотят именно этого. После чего коллеги взяли тайм-аут на подумать, и больше к этому вопросу уже сами не возвращались.
Вы невнимательно прочитали мой комментарий.
Речь шла про то, что бизнес просто механически комбинируя концепции "средний чек" и "показатель в разрезе отделения" придумали химерический показатель, который не демонстрирует ничего реального. А наш ИТ-директор вместо того, чтобы взять и тупо реализовать имеющееся ТЗ как оно есть, потратил своё время, чтобы подробно показать бизнесу, как этот показатель будет себя вести в разных бизнес-кейсах.
После чего бизнес сам понял, что такой показатель им не нужен.
PS: Если что — минус вам поставил не я, у меня нет возможности голосовать за комментарии.
Не, вы не поняли суть предложения.
Если ИИ использовать только для построения запроса, а потом этот запрос запускать по базе, то никаких выдуманных данных в выдачу не может попасть.
Тут проблема в другом — это будет работать только для простых и типовых ситуаций. В любых нетипичных ситуациях чтобы только правильно сформулировать задачу, человеку нужно будет ясно понимать структуру данных в базе и механику построения запроса к БД. И если человеку всё равно приходится вникать в такие тонкости, то ему и сам запрос удобнее и надёжнее будет описать на точном и формальном языке БД, а не на человеческом языке.
И для простых селектов это будет отлично работать. Для более сложных — только если человек хорошо представляет себе структуру данных в базе и нюансы построения запросов.
Я несколько лет назад работал в сети медицинских центров. И от бизнеса пришёл запрос реализовать построение отчёта в котором будет такая вещь как «средний чек по отделению». На все просьбы уточнить, что имеется в виду, бизнес отвечал: «Ну вы же знаете, что такое средний чек? Вот просто сделайте его в разрезе отделений». Заказчик сердился, что мы не понимаем такой простой вещи и тянем с выполнением задачи.
В итоге ИТ-директор усадил коммерческого директора за стол, обрисовал ему несколько типовых и краевых кейсов, и спросил — вот конкретно в этих ситуациях что именно вы ожидаете от «среднего чека в разрезе по отделениям». Коммерческий директор сказал, что он это обдумает и ответит чуть позже.
И больше с этой темой к нам никто не приходил.
И ведь до этого бизнес был истово уверен, что понимает, что конкретно он хочет.
А если бы с этим они обратились к нейросети, и она им какой-то отчёт по такому запросу построила бы? И люди бы потом по данным этого отчёта принимали бы какие-то управленческие решения.
Ну ок, вы взяли небольшие куски кода, и сравнили производительность по ним.
Но можно ли масштабировать эти выводы на картину в целом?
Если код написан ясно, то при необходимости изменить его, разработчик с большей вероятностью увидит более изящный и оптимальный способ сделать это.
Если же код написан запутанно, то с большей вероятностью разработчик будет править фрагмент кода без понимания того, как он взаимодействует с остальным кодом. И в итоге код будет представлять из себя лоскутное одеяло, где каждый лоскуток может работать очень быстро, но в итоге программа "почему-то" будет тормозной и забагованной.
Основная причина медленной работы ПО — халатность и рукожопие, а вовсе не следование каким-либо практикам.
Ну, на вскидку:
Использовать методологию ХХИВП можно на любом языке.
Питон только даёт возможность разрабатывать быстрее и проще, за что его ценят в том числе и последователи ХХИВП, но далеко не они одни.
Если нормально писать, то ничего не начнёт разваливаться. На любом языке можно писать плохо. И если питон за счёт низкого порога входа популярен среди слабых программистов, никак не свидетельствует о том, что питон сам по себе плох.
Бэкенд бэкенду рознь.
Если на нём вам нужно выполнять какую-то развесистую бизнес-логику, и нет совсем уж жёстких требований по производительности, то питон — лучшее, что вы можете выбрать в данном случае.
Но, конечно, если вам на бэкенде какую-то суровую числодробилку надо реализовать, то питон действительно брать не стоит.
Если воды литров 20 за раз выпить то можно и умереть. Но называть её из-за этого ядом — очень сильная натяжка.
В определении из википедии специально подчёркивается, что
А как же быть со всеми экспериментами, которые показывают скорость распространения гравитации равную скорости света с точностью порядка 10^-15?