Больные одной болезнью симпатизируют друг другу. Несчастные понимают друг друга.

Японская пословица.

Сегодня поговорим о различных электростанциях, которые появились в стране в дореволюционный период. Так как о электростанциях для освещения города я уже сказал ранее, то начнем с электрификации в промышленных зданиях. Там, если не считать гальванопластики, применявшейся с 1839 г., электричество начало использоваться с 70-х гг., поначалу только для освещения помещений. В 1873 г. было впервые организовано электроосвещение Сормовского завода, в 1877 г. Охтинского, в 1883 г. Обуховского и т. д. Причем для Охтинского и других пороховых заводов, подобная модернизация была долгожданной. До того момента, освещение на пороховых заводах могло стать причиной взрыва.

В 1882г. Н. Н. Бенардос изобретает дуговую электросварку, которую он именовал «электрогефестом». Это изобретение открывает новые возможности для промышленности и железнодорожного хозяйства. В 1888г. Н.Г. Славянов усовершенствует эту технологию и взамен угольных электродов использует плавящийся.

Что объединяет частицу в воде, биржевой курс и кота Барсика, бродящего по району в поисках ларька с рыбой?

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

Мы начнём с истории открытия броуновского движения — от наблюдений Роберта Броуна до формулы Альберта Эйнштейна, которая связала наблюдаемое явление с атомной гипотезой. Покажем, как идея случайного движения превратилась из гипотезы в надёжный инструмент научного анализа.

Затем перейдём к математической модели случайных блужданий, разберём, как она устроена и где используется. Научимся с ней работать: найдём среднюю скорость удаления, обсудим задачу о разорении игрока и вернёмся к нашему коту Барсику.

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

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

SSTV (slow-scan television) — телевидение с медленной разверткой, узкополосный формат передачи данных, позволяющий передавать изображения через эфир. В этой статье будут рассмотрены подробности кодирования, декодирования SSTV-сигнала.
Статья может быть интересна радиолюбителям, желающим познакомиться с новым форматом связи, а также тем, кто хочет в подробностях понять как же работает эта технология.

У меня возникла идея, как можно расширить синтаксис C++ операцией скалярного произведения. Если кратко, то произведение двух матриц в новых обозначениях будет выглядеть так:

C[>i][>j] = A[i][>k] * B[>k][j];

Насколько мне известно, сочетания операторов [> и [< вроде бы нигде не используются. Их можно применить для декларации индексов, которые существуют только в пределах данного выражения. Сочетание [> используется для декларации индекса, который пробегает от начала до конца массива в прямом направлении, а сочетание [< для декларации индекса, который пробегает в обратном направлении. Для повторяющихся индексов в произведении подразумевается суммирование - они аналогичны немым индексам в тензорных обозначениях.

Разберём на примерах, как это будет работать.

Разработка проектного решения и документирование активностей по его воплощению на производстве больших ИТ-продуктов, процесс длительный, поэтапный, к тому же очень кропотливый и требующий слаженной работы разношерстного коллектива. Поэтому с самого начала необходимо продумать и подготовить ландшафт (среду обитания), в которой это процесс будет проистекать. Из моего опыта, если команда обеспечена комфортной средой для работы с артефактами проекта, а также для коммуникации участников между собой, то она уже на 50% обеспечила успешное развитие проекта.

Цель данной группы работ: подготовить условия для качественного и эффективного взаимодействия команды проекта в рамках разработки и реализаций требований к целевому продукту.

Чтобы глубже познать принципы организации такого ландшафта давайте рассмотрим модель того, как обычно происходит взаимодействие в команде.

Долгих дней и приятных ночей! Меня зовут Натали, я IT Project Manager со стажем 10+ лет. В данной статье хочу поднять вопрос негативного влияния добровольно‑принудительных командировок удаленщиков в офис как на сотрудников, так и на компанию вцелом. Особенно первый раз. Особенно для интровертов. Статья будет полезна руководителям, проджектам, HR и любому it‑специалисту (возможно вы узнаете себя, и убедитесь что вы такой не один). Поехали!

Представим, что вы — руководитель (тимлид, ПМ, Head of PMO, не столь важно). Работаете в крупной компании в Москве, следите за финансовыми метриками успешности проекта/компании. Под вашим руководством распределенная команда — многие работают в Москве на гибриде, кто‑то всегда из дома, кто‑то из других городов. В какой то момент вы раздумываете над вопросом — а как увеличить эффективность команды? Часто на этом этапе руководители приходят к мысли, что нужно, как это сейчас модно, «сплотить» команду — и все сразу станут более производительными, чаще будут писать друг другу, просить и оказывать помощь, охотнее говорить о проблемах и быстрее придумывать решения.

Часть 2: Настройка GitHub Actions и GitLab CI – первый workflow и деплой

В первой статье мы разобрались с основами CI/CD: что это такое, зачем нужно и какие инструменты существуют. Теперь пришло время перейти от теории к практике – создадим наши первые рабочие CI/CD-конвейеры на GitHub Actions и GitLab CI.

По своему опыту преподавания информатики и программирования регулярно замечаю, что вдумчивые начинающие программисты, отличающиеся внимательным отношением к различным деталям применяемых в программировании терминов, не редко впадают в ступор, изучая переведённые на русский язык книги известных на Западе программистов: М. Лутц, Дж Гл. Брукшир, М. Саммерфильд, М. Прайс, J.P. Мюллер, J. Албахари и т.д.  Например, чем отличается Statement, Operator, Instruction, и почему они так переводятся на русский язык?

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

Однако для тех начинающих программистов, кто хочет выстроить стройную систему знаний такой ответ явно не подходит. И почему знания должны быть искажёнными, некорректными, если он тратит время на обучение, лучше сразу выучить правильно, чем потом переобучаться. Это культура знаний. Помню, когда ещё был молодым адъюнктом, решил на актуальные для себя темы поговорить (пообсуждать) с учёным со стажем, он послушал меня, рассмеялся и сказал: «Давайте сначала мы договоримся о терминах, а потом пообсуждаем Ваши вопросы. Вы не тушуйтесь, это обычная ситуация, все через это проходят.» Применительно к IT, когда наш специалист в беседе с западными применяет словосочетание, например, if operator, вместо if statement – это режет слух. Но нравоучения вряд ли кому понравятся, поэтому перейдём к нашей теме.

Пять лет назад я сделал некоммерческий проект с немного провокационным названием — «Школа брата Антония». Это был базовый курс по изучению программирования на языке Swift. Тогда я утверждал, что существует явное окно возможностей, которым стоит воспользоваться. Впоследствии я получил десятки писем с благодарностью — люди писали, что это действительно был хороший совет. Многие решились на изменения в жизни — и не прогадали. Бывшие электрики, продавцы, HR-специалисты, стоматологи (за врачей мне немного стыдно), хирург (тут я чувствую себя ещё хуже) смогли устроиться на высокооплачиваемую работу. Кландайк.

Но в 2025 году пришло время признать, что ландшафт серьёзно изменился. Вместо окна возможностей осталась форточка. В неё сложно, но всё ещё можно запрыгнуть.

Как преподаватель, могу сказать, что студентам непросто бывает привести базу данных к какому‑то осмысленному виду (не говоря уже про третью нормальную форму). Во‑первых, нередко «всё связано со всем», во‑вторых, в мало‑мальски сложной (в смысле, комплексной) задаче бывает трудно правильно спроектировать таблицы (то есть определить, какие таблицы должны быть в базе, как они должны быть связаны друг с другом, где и какая информация должна в них храниться). Помогает ли им в этом теория? И да, и нет. Дело в том, что нормализация данных говорит о желаемом виде каждой таблицы, и, преобразуя отдельно взятую таблицу к нормальной форме, мы также что‑то делаем со всей базой данных (добавляем новые таблицы, перемещаем между ними поля, и так далее) — это как сборка кубика Рубика. Второй проблемой здесь является то, что даже база данных, состоящая из единственной таблицы, не приведенной к первой нормальной форме, внезапно, тоже будет работать — криво‑косо, но будет! Теория — штука хорошая, но кое‑чего ей не хватает, а именно — задания точки отсчёта. Ведь для того, чтобы пройти к библиотеке третьей нормальной форме, для начала нужно понимать, где мы находимся.

Константин Евтеев @beginner760собирает Java-код с помощью диктора NVDA, редактирует его в Блокноте и передает на Linux по SSH через самописные bash-скрипты. После потери зрения он не потерял интереса к жизни и желания быть полезным и выстроил собственную инженерную экосистему: оглавления по строкам .txt-файлами, навигация по main и маленьким методам, отладка на слух.

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

Привет! Меня зовут Илья, последние 7 лет я занимаюсь фронтендом и наконец решил отметиться на Хабре. Стартую с темы, которая, как кажется, уже успела приесться, но всё ещё вызывает жаркие споры — код ревью (CR). Не смотря на сотни статей и мануалов, каждая команда подходит к этому процессу по‑своему. Хочется зафиксировать и осмыслить собственный опыт, показать, как мы подходили к настройке процесса в реальном проекте, и почему, на мой взгляд, код‑ревью не может быть универсальным, а должен опираться на контекст команды.

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

14.05.2025, Редакционная Группа NASA Science

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

Инженеры Лаборатории реактивного движения NASA в Южной Калифорнии восстановили ряд двигателей на борту космического корабля Voyager 1, которые считались неисправными с 2004 года. Ремонт потребовал креативности и риска, но команда хочет иметь их в качестве резерва для работающих двигателей, в топливных трубках которых накапливается остаток, что может привести к их выходу из строя уже этой осенью.

Привет, Хабр! Меня зовут Катя, я лидирую Gramax, open source-платформу для управления технической документацией. Однажды мы с коллегами утонули в хаосе рабочих документов: без версий, без согласований, без истории принятых решений. Это подтолкнуло нас к созданию Gramax — инструмента, который интегрирует документацию в процесс разработки, делая его прозрачным и управляемым.

В этой статье расскажу, как Gramax помогает на каждом этапе разработки ПО. Как перейти к документированию в подходе Docs as Code и шагнуть дальше — к Everything as Code.

Привет! Меня зовут Алексей Стратонов, я экс-техлид Авито Недвижимости. До Авито я 8 лет проработал в аутсорсе: управлял четырьмя отделами, успел нанять и уволить многих, в том числе руководителей. В аутсорсе есть специфика — зарплаты тут ниже, а задачи те же, что и в продукте. Поэтому тимлид должен уметь собирать команды под определенный проект и качественно собеседовать.

В статье рассказываю, какие моменты напрягают меня в кандидатах, а какие, наоборот, подкупают. Этот текст будет полезно прочитать молодым лидам, которые только начинают нанимать самостоятельно. Если вы уже уверенно чувствуете себя на собеседованиях, то все, что я упомянул, покажется вам знакомым. Но проверить свои знания не помешает :-)

Говорят, что невозможно по-настоящему возненавидеть кого-то, если сначала не полюбил его. Не знаю, справедливо ли это в целом, но это определённо описывает моё отношение к NumPy.

NumPy — это ПО для выполнения вычислений с массивами на Python. Оно невероятно популярно и очень сильно повлияло на все популярные библиотеки машинного обучения, например, на PyTorch. Эти библиотеки во многом имеют те же самые проблемы, но для конкретики я рассмотрю NumPy.