Существует глубокая и, по моему мнению, парадоксальная аналогия между двумя на первый взгляд несопоставимыми задачами: построением непротиворечивой математики и доказательством существования Бога. Обе они преследуют идеал абсолютной достоверности и завершенности знания. И обе наталкиваются на непреодолимые препятствия, вырастающие из самой природы человеческого разума.

Лично меня этот вопрос занимает уже много лет: является ли это совпадением, или же мы обнаруживаем здесь универсальный предел человеческого мышления?

Попробуем применить многомерный анализ к данным временных рядов с помощью интерактивной визуализации данных измерений и их взаимосвязей.

Электричество глубоко пронизывает жизнь человека. Порой даже сложно представить, насколько сильно мы зависим от этого удивительного физического явления.

Само функционирование человеческого организма является следствием биоэлектрических процессов. Наш организм — своеобразная электростанция, которая всегда с тобой (возможно, вам в детстве доводилось играть с маломощными светодиодами, которые начинали светиться от соприкосновения с кожей?). Основные источники электрического тока в нашем организме — нервная система и мышечная ткань. Нервная система представляет собой сложную электрическую сеть, по которой ежесекундно передаются тысячи импульсов. Эти импульсы генерируются нейронами в ответ на внешние раздражители. Фактически, именно благодаря им мы способны ощущать и осознавать окружающий мир.

Разработчики делают задания ради галочки, в их глазах больше не горит огонь, а число инновационных идей от девелоперов уменьшилось? Нет, сотрудники не обленились. Им просто не хватает мотивации для эффективной работы. Разбираемся вместе с командой системы управления проектами Kaiten и консультантом по современному менеджменту Neogenda Марией Савельевой, как вернуть мотивацию IT-команде. 

Вот удивительный эксперимент, который вы можете попробовать провести у себя дома: соберите несколько игрушечных блоков и положите их на стол. Возьмите один блок и медленно, сантиметр за сантиметром, продвигайте его за край стола, пока он не окажется на грани падения. Если у вас есть терпение и твёрдая рука, у вас должно получиться сбалансировать его так, чтобы ровно половина свисала с края. Стоит сдвинуть его ещё дальше, и гравитация победит. Теперь возьмите два блока и начните сначала. Укладывая один блок на другой, как далеко вы сможете завести конец верхнего блока, чтобы он высунулся за край стола?

modern-i18n — это легковесная библиотека для интернационализации Python-проектов. Она позволяет легко управлять переводами, использовать параметризованные строки для форматирования текста. Подходит для небольших и крупных проектов.

В данной статье мы разъясним вопрос, который, находясь в самой основе теоретического программирования, при этом парадоксальным образом очень часто объясняется неправильно или неполно, причём эти неправильные объяснения даже иногда входят в учебные пособия (по крайней мере, известный китайский чатбот не смог мне правильно ответить на вопрос об отличии машины Тьюринга от конечного автомата, хотя, казалось бы, они приходятся чатботу ближайшими родственниками, и он мог бы изучить область деятельности своих создателей в обучающей выборке).

А в конце мы немного пофилософствуем на тему, что же такое программа и что такое семантика.

На прошлой неделе S0ER опубликовал пост о том, что в собеседованиях укоренилась практика проверять знание каких-то фактов, а не умение мыслить. Будто ищется условный чат-гпт с большой базой знаний, а не специалист, способный анализировать и решать задачи. Хотя ИИ как раз тестируют так, как надо наоборот бы тестировать человека.

Этот материал побудил меня порефлексировать над своим опытом в найме, вспомнить недавние кейсы и подумать о формирующихся тенденциях. Конечно, в этих рассуждениях не обошлось без AI.

Меня зовут Рома и это вторая часть цикла «Типы и структуры данных Go». В этот раз будем разбираться с внутренностями строк. Говорить будем только о том, что есть в базе языка, то есть без дополнительных функций из стандартной, экспериментальной или какой-либо другой библиотеки.

Приятного аппетита!

Писать код, который достаточно бегло просмотреть — не менее важно, чем писать код, который в принципе можно прочитать. Давайте немного поговорим о «форме» кода — такой, чтобы по структуре кода можно было быстро понять, для чего он, и сократить время работы с кодовой базой.

Тут в глубине комменатриев зашла речь о создании видимости работы в ущерб самой работе — когда количество закрытых тасков ценится (менеджерами) выше чем докопаться до причины бага и устранить ее. Комментарий получился бы большеват, решил вынести в отдельный пост.

Суть:

В эпоху цифровизации промышленности всё больше компаний понимают: стандартизация программного обеспечения — это не просто формальность, а мощный инструмент для управления рисками, сокращения затрат и повышения стабильности работы производства.

Сегодня автоматизированные системы управления технологическими процессами (АСУ ТП) становятся всё более «программно-ориентированными». Если раньше основным считались контроллеры и оборудование, то сейчас главная ценность — это софт: логика процессов, алгоритмы управления, интерфейсы операторов и интеграция с другими уровнями автоматизации.

В этой статье расскажу, как стандартизация программного обеспечения помогает эффективнее обслуживать АСУ ТП и какие реальные выгоды она приносит предприятиям.

ITSM живет с нами уже 30 лет. За это время многое изменилось: технологии, версии ITIL, бюджеты на реализацию. Что осталось неизменным — так это завышенные ожидания, которые часто идут вразрез с реальностью.

Напомню, что ITSM (Information Technology Service Management, Управление ИТ-услугами) — это подход к управлению ИТ-деятельностью, который рассматривает ИТ-ресурсы как услуги, предоставляемые бизнесу для достижения его целей.

Сегодня я хотел обсудить самые распространенные «мифы», которые громогласно и красиво рассказывают со сцен отраслевых мероприятий и на вебинарах признанные специалисты, консультанты, продавцы, эксперты в области ITSM, и то, как потом эти «мифы» разбиваются о скалы суровой реальности.

Миф № 1: Я легко пройду сквозь бюрократию и быстро внедрю сервисный подход! Ведь это же прогресс и инновации, за этим будущее!

Реальность: нет, это будет долго и больно.

Всем привет! И снова с вами Илья Криволапов – системный аналитик в SENSE, где мы вместе с командой трудимся над проектом одного из цветных банков РФ. Напоминаю, что в профессии я уже больше пяти лет и, несмотря на фамилию, прод все еще живой и здоровый (ну почти)!

В свободное от работы время, я преподаю курс «Хранение и обработка больших объемов данных», где успел накопить немало наблюдений, кейсов и выводов, которые не хочется держать в столе. Поэтому всё самое полезное оформил в цикл статей на Хабре – рассказываю как строить базы данных с прицелом на рост и не сойти с ума под нагрузкой.

В первой части мы говорили о базовых стратегиях масштабирования: вертикальной и горизонтальной. Покрутили в руках репликацию, рассмотрели кейсы, когда и как можно к ней обращаться. Во второй углубились в шардинг и разобрали три популярных подхода: по диапазону, хэшу и геозонам. А сегодня будет финальная, третья часть. В ней мы рассмотрим ещё три способа шардирования: директивный, круговой и динамический. Расскажу, как они устроены, когда применяются, в чём их сильные стороны и где скрывается подвох.

Материал будет полезен всем, кто проектирует, масштабирует или просто поддерживает «здоровье» базы данных: DBA, архитекторам, DevOps-инженерам, аналитикам и разработчикам.

Финальный рывок – поехали!

«Функциональное программирование», «Immutable значения», «Pure функции».
Тоже слышал эти умные слова?

И ты такой: «Что? Можно просто for написать?»

Спокойно. Сейчас все разложим по полочкам. Даже если ты пишешь var a = 1 и гордишься этим — ты свой. Погнали.

Всем привет. Я сетевой инженер, работаю в интернет провайдере. Примерно год назад начал внедрение Netbox для документирования сети. Здесь я расскажу как я добавил коммутаторы доступа скриптом, через API Netbox. Скрипт добавления устройств в Netbox через API является универсальным и подойдёт всем. А так же расскажу, как я добывал первичные данные о коммутаторах, здесь уже мои скрипты помогут не всем, т.к. топология сети и настройки могут сильно отличаться, и методов сбора данных может быть не один десяток.

Сравнение PyBind11 vs ctypes

В принципе, можно вызывать C++ из Python двумя способами: при помощи библиотеки PyBind11 для C++, которая готовит модуль Python, либо при помощи пакета cytpes для Python, который предоставляет доступ к скомпилированной разделяемой библиотеке. Работая с PyBind11, не составляет труда совместно использовать множество типов данных, в то время как ctypes — это гораздо более низкоуровневое решение в стиле C.

Взявшись за описанный здесь проект, я хотел рассчитывать на производительность и переносимость C++, но так, чтобы не жертвовать интерактивностью интерпретируемых языков, которая удобна для экспресс-исследования и отладки.

К счастью, вызывать C++ из Python не так сложно, как может показаться на первый взгляд. Таким образом, можно в какой-то степени позаимствовать интерактивность Python при разработке кода C++.

Привет! Это Леша Жиряков, я руководить бэкенд-команды витрины KION и Python-гильдии в МТС. Как раз о Python сегодня и пойдет речь. Обсудим, почему самый популярный ЯП, по версии TIOBE, так востребован в корпоративном секторе: из простого инструмента автоматизации он превратился в полноценную экосистему для создания критически важных продуктов.

Если коротко, причина успеха — в эволюции языка и его экосистемы. Аннотации типов в Python 3.5 сделали доступной статическую проверку кода без потери гибкости динамической типизации. Это решающий фактор для корпоративной разработки, ведь главные требования тут — это надежность и поддерживаемость.

Недавно я уже писал о причинах успеха Python в целом, а сегодня хочу подробно рассмотреть его современные инструменты для предприятий: типизированные структуры данных с dataclasses, высокопроизводительные системы валидации msgspec, pydantic 2 и другие библиотеки. То есть все, что помогло ему стать идеальным выбором для серьезных бизнес-решений. Информации много, так что тему разобью на две части. Погнали!

Самый главный страх обывателя, живущего неподалёку от любой ГЭС — это то, что плотина не выдержит. Страшно. Страшно, что вода смоет тело плотины, или перевернёт весь этот бетонный щит, или просочится по трещинам, или хотя бы перехлестнёт через гребень — а уж тогда все эти накопленные в водохранилище миллионы кубометров устремятся вниз, сметая всё на своём пути. И число жертв рукотворного цунами пойдёт на многие десятки тысяч...

Привет, Хабр!

Если вы ощущаете, что стали частью распределённой системы с бесконечными входящими — поздравляю, вы тимлид. И, скорее всего, вам не весело. Вы не пишете код. Вы не думаете стратегически. Зато вы таскаете ведро с пробоинами по палубе, где вечно течёт.

У большинства тимлидов, особенно в условиях активного роста компании или распределённой разработки, есть общее ощущение перегруженности. Неважно, какая индустрия, стек, удалёнка или офис — ощущение одно: «весь день был занят, но результат размыт».