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

Ритейл, банки, технологические предприятия, компании-разработчики и все те, кто собирает большие массивы неструктурированных данных, для запуска сложных моделей могут использовать вычислительные ресурсы облака. Например, строить нейросети с помощью ML-платформы или использовать объектное хранилище для обработки Big Data.

Но чтобы грамотно использовать инструменты для работы с AI- и ML-задачами, нужно приобрести необходимо знания и навыки. Поможет разобраться в машинном обучении и инструментах для работы с ML-моделями подборка новых и высокооцененных специализированных курсов, книг и других тематических материалов.

На работе вам, как правило, встречаются три типа личности: тип А, тип В и тип IT. Последние сильно отличаются от остальных. Мы выделили восемь классических типов личности, которые вы найдете практически в любом достаточно крупном IT-отделе. Некоторые из них это Костюмы, которые были отправлены в IT против своей воли, или Акулы продаж, которые с удовольствием продадут лед эскимосам, как только закончат продавать песок саудитам. В общем, под катом путеводитель по флоре и фауне IT-отдела.

Привет, Хабр! В этой статье я хочу поделиться ситуацией из своего опыта работы, связанной с появлением в команде тимлида, который, к сожалению, не смог завоевать авторитет, зато получил псевдоним "Терплид".

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

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

В этой статье рассмотрим как эти принципы применяются в golang.

Дмитрий Королёв, бэкенд-разработчик в Авито, разобрал на примерах, чем отличаются друг от друга форматы сериализации данных, и как выбрать самый удобный.

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

В статье попробуем разобраться действительно ли роль архитектора незаменима, для чего она нужна, как возникла и работает в реальном мире?

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

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

Вчера чат-бот с искусственным интеллектом ChatGPT написал за меня Android-приложение! Это очень примитивное приложение, но оно компилируется, запускается и работает. Но как он это сделал? С первой попытки или пришлось долго сидеть и мучить его?

Сейчас расскажу!

Низкий порог входа и строгость языка программирования — вещи обычно несовместимые. Потому что ты либо, как Rust, бьёшь по рукам borrow checker’ом — либо, как PHP, позволяешь не задумываться о типах и быстро прототипировать. 

На самом деле, если писать код грамотно, это становится неважным и язык перестаёт иметь значение. Архитектура важнее языка, и хороший код на PHP ничем не отличается от аналогичного кода на любом другом ООП-языке. Другое дело, что возможность «любой домохозяйке» писать на PHP сопровождается и риском наворотить полное неподдерживаемое безобразие. Поэтому нам нужны тайпхинты, линтеры, статические анализаторы и подобные инструменты. 

Но в PHP есть и ещё один изъян: в нём любой класс, функция или константа — глобальны. Можно создать класс из любого места в коде, и нет способа скрыть его или сделать деталью реализации где-то в отдельной папке. Иными словами, в PHP нет того, что в других языках называется модулями.

Наша новая open-source разработка называется Modulite и внедряет в PHP модули. Это сквозная технология: мы внедряемся в IDE, в PHPStan, в KPHP, в CI, в Composer — и делаем так, будто бы модули нативно есть в языке PHP.

Продолжаем лекции по управлению в технических системах предыдущие части:

1. Введение в теорию автоматического управления.2. Математическое описание систем автоматического управления 2.1 — 2.3, 2.3 — 2.8, 2.9 — 2.13.

3. ЧАСТОТНЫЕ ХАРАКТЕРИСТИКИ ЗВЕНЬЕВ И СИСТЕМ АВТОМАТИЧЕСКОГО УПРАВЛЕНИЯ РЕГУЛИРОВАНИЯ. 3.1. Амплитудно-фазовая частотная характеристика: годограф, АФЧХ, ЛАХ, ФЧХ. 3.2. Типовые звенья систем автоматического управления регулирования. Классификация типовых звеньев. Простейшие типовые звенья. 3.3. Апериодическое звено 1–го порядка инерционное звено. На примере входной камеры ядерного реактора. 3.4. Апериодическое звено 2-го порядка. 3.5. Колебательное звено. 3.6. Инерционно-дифференцирующее звено. 3.7. Форсирующее звено.  3.8. Инерционно-интегрирующее звено (интегрирующее звено с замедлением). 3.9. Изодромное звено (изодром). 3.10 Минимально-фазовые и не минимально-фазовые звенья. 3.11 Математическая модель кинетики нейтронов в «точечном» реакторе «нулевой» мощности.

4. Структурные преобразования систем автоматического регулирования.

5. Передаточные функции и уравнения динамики замкнутых систем автоматического регулирования (САР).

Теперь перейдем к устойчивости!

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

Для IT компаний архитектура — базис, на котором выстраиваются все продукты и подходы. Но, у архитектуры тоже должна быть основа. Интересно, что будет, если мы будем выстраивать её из ценностей? Не тех, которые плакатами развешаны на кухне, а тех, которые живут «в курилке», на которых сформировалась компания и коллектив.

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

Решение — подход DDD, Domain Driven Design, было предложено Эриком Эвансом в 2003. Но прежде, чем о нем говорить, необходимо немного углубиться в историю развития разработки софта как такового.

Представьте, что у вас есть функция random(), которая генерируют случайным образом значения в промежутке

Вычислите значение числа

Это задачка с реального собеседования, будем разбираться!

Началась эта история в августе 2020 года. Скучая в отпуске, я рылся в интернете с весьма определенной целью - "что бы еще прикупить и засунуть в свой умный дом..". И попалось мне на глаза очень интересное устройство.

Миша – удивительный чувак. Поразительный и заразительный. Лучший руководитель в региональной IT-компании. Ещё и офигенный программист.

Мы разговаривали всего полчаса, а он успел меня заразить. Вот вы сейчас о чём подумали? Ну, явно не о насморке… Наверное, что он увлечённо рассказывает о повышении эффективности? Новых технологиях? Цифровизации? И я прям такой наслушался и кинулся статью писать?

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

И его лень заразительна. Так заразительна, что мне лень писать много букв. В кои-то веки буду краток.