И как бы философия тут помогла?
Только без общих слов про то, что философия является базой в вопросах этики.
Как раз-таки привычка предаваться философии делает человека уязвимым к манипуляциям через такие пропагандистские концепции как "историческая справедливость", "национальное самосознание", "национальная идея" и т.п.
Здоровому человеку не нужна философия, чтобы понимать, что война — плохо.
Как вы сформулируете эти "общие вопросы", не занимаясь предварительно частностями?
В реальности контуры общих вопросов можно наметить только после того, как произведена какая-то работа на массиве частных вопросов.
Без этого попытка выглючить общие вопросы из головы порождает только пустые химеры.
В античности и средние века под философией понимали вообще всё, что не являлось прикладным знанием.
После того, как оформился научный подход, всё ценное выделилось из философии в отдельные научные направления — логику, психологию, естественные науки, методологию и тд, и тп. Осталась только всякая ментальная шелуха, не обладающая никакой ценностью.
И говорить, что этот шлак обладает ценность, потому что "все другие науки произошли от него", это всё равно, что превозносить алхимию. То есть да, алхимики сделали много открытий и разработали много методик работы с веществом. Но после появления полноценной химической науки алхимию можно сдавать в утиль.
Мне в этом плане нравится утверждение, что в питоне фактически присутствует то, что можно назвать Gradual Typing (постепенная типизация).
То есть простой и очевидный код или прототип мы можем писать и менять очень быстро без заморочек с типами. А когда код стабилизируется и начинает обрастать логикой, мы можем постепенно вводить типы, основываясь на уже настоявшихся абстракциях.
Это даёт гибкость, но действительно требует определённой культуры разработки, которая не у всех есть.
Впрочем, в последние годы всё больше вижу, что народ распробовал аннотирование типов.
Я некоторое время провёл, внося изменения в питоновский код, где в половину функций передавались аргументы params или opts, или сразу оба вместе. Каждый из них был словарём с переменным набором параметров/опций, причём они не формировались в одном месте, а прокидывались через много уровней, и их содержимое могло обогащаться/изменяться по ходу этого прокидывания.
То есть не было никакого спосбоа узнать, а какие ключи в принципе там могут лежать, и в каком формате их значения. Эту информацию приходилось собирать по крупицам, ползая по всему коду.
Если бы вместо словарей тут использовались нормальные датаклассы с типизированными значениями, то это лишь чуть-чуть увеличило бы трудозатраты при написании, но значительно сократило бы их при доработке, отладке и расследовании инцидентов. И дополнительно снизило бы вероятность ошибок и количество потраченных нервов.
А ещё — даже если ИИ действительно сочтёт людей самой интересной вещью во Вселенной, то из этого никак не следует, что он будет непременно дружественным.
Он очень легко может прийти к мысли, что пассивное наблюдение за объектом изучения — не самый лучший метод познания, и гораздо эффективнее — активные эксперименты.
Мартин в каком-то из интервью говорил, что причины климатического хаоса в Вестеросе — магические, а не астрономические, и это будет объяснено в конце саги.
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: Если что — минус вам поставил не я, у меня нет возможности голосовать за комментарии.
И как бы философия тут помогла?
Только без общих слов про то, что философия является базой в вопросах этики.
Как раз-таки привычка предаваться философии делает человека уязвимым к манипуляциям через такие пропагандистские концепции как "историческая справедливость", "национальное самосознание", "национальная идея" и т.п.
Здоровому человеку не нужна философия, чтобы понимать, что война — плохо.
Как вы сформулируете эти "общие вопросы", не занимаясь предварительно частностями?
В реальности контуры общих вопросов можно наметить только после того, как произведена какая-то работа на массиве частных вопросов.
Без этого попытка выглючить общие вопросы из головы порождает только пустые химеры.
В античности и средние века под философией понимали вообще всё, что не являлось прикладным знанием.
После того, как оформился научный подход, всё ценное выделилось из философии в отдельные научные направления — логику, психологию, естественные науки, методологию и тд, и тп. Осталась только всякая ментальная шелуха, не обладающая никакой ценностью.
И говорить, что этот шлак обладает ценность, потому что "все другие науки произошли от него", это всё равно, что превозносить алхимию. То есть да, алхимики сделали много открытий и разработали много методик работы с веществом. Но после появления полноценной химической науки алхимию можно сдавать в утиль.
Мне в этом плане нравится утверждение, что в питоне фактически присутствует то, что можно назвать Gradual Typing (постепенная типизация).
То есть простой и очевидный код или прототип мы можем писать и менять очень быстро без заморочек с типами. А когда код стабилизируется и начинает обрастать логикой, мы можем постепенно вводить типы, основываясь на уже настоявшихся абстракциях.
Это даёт гибкость, но действительно требует определённой культуры разработки, которая не у всех есть.
Впрочем, в последние годы всё больше вижу, что народ распробовал аннотирование типов.
Я некоторое время провёл, внося изменения в питоновский код, где в половину функций передавались аргументы params или opts, или сразу оба вместе. Каждый из них был словарём с переменным набором параметров/опций, причём они не формировались в одном месте, а прокидывались через много уровней, и их содержимое могло обогащаться/изменяться по ходу этого прокидывания.
То есть не было никакого спосбоа узнать, а какие ключи в принципе там могут лежать, и в каком формате их значения. Эту информацию приходилось собирать по крупицам, ползая по всему коду.
Если бы вместо словарей тут использовались нормальные датаклассы с типизированными значениями, то это лишь чуть-чуть увеличило бы трудозатраты при написании, но значительно сократило бы их при доработке, отладке и расследовании инцидентов. И дополнительно снизило бы вероятность ошибок и количество потраченных нервов.
А ещё — даже если ИИ действительно сочтёт людей самой интересной вещью во Вселенной, то из этого никак не следует, что он будет непременно дружественным.
Он очень легко может прийти к мысли, что пассивное наблюдение за объектом изучения — не самый лучший метод познания, и гораздо эффективнее — активные эксперименты.
Вроде бы Яндекс.Трекер вполне можно потыкать в облаке, а для маленьких команд до 5 человек он бесплатен.
И раз уж зашла речь про БД, то в них есть индексы на основе хэша.
Мартин в каком-то из интервью говорил, что причины климатического хаоса в Вестеросе — магические, а не астрономические, и это будет объяснено в конце саги.
Вот так получается на питоне:
Хорошая мысль, я займусь этим в выходные.
Я просто счёл нужным оставить этот коммент на тот случай, если статью будет читать кто-то, кто пока не ориентируется в языках, но присматривает подходящий инструмент автоматизации )
Можете считать это глубоким имхо, но я должен это написать:
Я про САП ничего не знаю :(
Можете объяснить на пальцах, как можно в монолите независимо масштабировать/деплоить части системы?
Очень зависит от специфики конкретного сервиса.
Если возникает необходимость независимо масштабировать части систему — монолит в пролёте.
Если возникает необходимость независимо выкатывать части системы — монолит в пролёте.
Ну а единая БД может быть и при микросервисной структуре (правда, многие считают это анти-паттерном).
Чтобы натыкались только намеренно? )
А если понадобиться не просто изменить константу, а поменять саму логику?
Например, бизнес скажет, что теперь заказ истекает через семь дней только в тех случаях, если в момент его создания луна была в четвёртом доме.
И такие изменения могут происходить многократно. Поверьте мне, вы не захотите каждый раз менять это в дюжине разных мест.
Это вы хотите дальше поспорить, у меня такого намерения вообще не было.
Ещё раз повторяю: коллег со стороны бизнеса мы не отфутболивали. Мы обрисовали им как будет себя вести этот показатель на разных бизнес-кейсах, и спросили — точно ли они хотят именно этого. После чего коллеги взяли тайм-аут на подумать, и больше к этому вопросу уже сами не возвращались.
Вы невнимательно прочитали мой комментарий.
Речь шла про то, что бизнес просто механически комбинируя концепции "средний чек" и "показатель в разрезе отделения" придумали химерический показатель, который не демонстрирует ничего реального. А наш ИТ-директор вместо того, чтобы взять и тупо реализовать имеющееся ТЗ как оно есть, потратил своё время, чтобы подробно показать бизнесу, как этот показатель будет себя вести в разных бизнес-кейсах.
После чего бизнес сам понял, что такой показатель им не нужен.
PS: Если что — минус вам поставил не я, у меня нет возможности голосовать за комментарии.