Как стать автором
Обновить
11
0
Сергей Клевакин @Justerest

Пользователь

Отправить сообщение

Как работает ChatGPT: объясняем на простом русском эволюцию языковых моделей с T9 до чуда

Уровень сложности Простой
Время на прочтение 30 мин
Количество просмотров 364K

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

Погнали →
Всего голосов 357: ↑350 и ↓7 +343
Комментарии 283

Разбираемся с Redis

Время на прочтение 19 мин
Количество просмотров 221K

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

Читать далее
Всего голосов 64: ↑63 и ↓1 +62
Комментарии 7

Инди-дев-(б|в)лог: 1.0.0 — Инициализация

Время на прочтение 10 мин
Количество просмотров 1.3K

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

В моей голове подобный проект всегда выглядит, как несбыточная мечта, однако, на протяжении моей карьеры, где на данный момент я - Lead Full Stack Software Development Engineer, где Full Stack - это полный цикл разработки включающий Technical writing, QA, SDET, SDE, Architecture, BA, DBA, UI/UX и так далее, наконец-то сформировался концепт проекта мечты и, собственно, план по реализации, осталось дело за малым.

Читать далее
Всего голосов 5: ↑4 и ↓1 +3
Комментарии 1

Генерация лабиринтов: алгоритм Эллера

Время на прочтение 6 мин
Количество просмотров 25K

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

Сегодня я хотел бы рассказать о генерации идеального лабиринта - алгоритмом Эллера. Статья подойдёт всем любителям алгоритмов.

Читать далее
Всего голосов 51: ↑51 и ↓0 +51
Комментарии 10

Rust Embedded. Разработка под процессоры Cortex-M3 на примере отладочной платы STM32F103C8T6 (Black Pill)

Время на прочтение 7 мин
Количество просмотров 29K
Привет! Хочу познакомить вас с проектом Rust Embedded. Он позволяет нам использовать язык программирования Rust для разработки под встроенные платформы (Embedded Linux / RTOS / Bare Metal).


В этой статье, мы рассмотрим компоненты, которые необходимы для начала разработки под микропроцессоры Cortex-M3. После этого напишем простой пример — моргание встроенным светодиодом.
Читать дальше →
Всего голосов 48: ↑47 и ↓1 +46
Комментарии 40

План самостоятельного обучения DDD, CQRS, EventSourcing

Время на прочтение 7 мин
Количество просмотров 38K

Если вы собрались плотно погрузиться в тему Doman Driven Design (DDD), о том как его применять, как использовать, для чего он нужен, и как с ним связаны Command and Query Responsibility Segregation (CQRS), Event Sourcing и другие термины из мира DDD то можно воспользоваться планом обучения, который последовательно погрузит вас в эти темы и поможет сориентироваться. Часть информации на русском, часть на английском языке, так как русскоязычных аналогов я не смог найти.

Погрузиться в DDD
Всего голосов 36: ↑35 и ↓1 +34
Комментарии 4

Как понять, что перед вами плохой разработчик

Время на прочтение 12 мин
Количество просмотров 178K

Мало просто сменить свою сферу работы на IT, желательно еще и стать хорошим разработчиком. Бывший тимлид и консультант Александр Усков рассказывает, как понять, что перед вами плохой разработчик и что с ним вообще можно делать

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

Читать далее
Всего голосов 301: ↑197 и ↓104 +93
Комментарии 402

Системный архитектор. Кто этот человек?

Время на прочтение 10 мин
Количество просмотров 18K

Для кого эта статья? Эта статья, также как и первая, рассчитана на людей, работающих в сфере ИТ.  Для разработчиков, тестировщиков, менеджеров разного уровня, аналитиков и т.д. Для расширения кругозора, она также может быть полезна и всем остальным, просто, чтобы иметь представление о том, чем занимается Системный Архитектор.  Пригодится материал и тем, кто планирует развитие своей профессиональной карьеры, и тем, кто выкладывает такого рода вакансию и ищет специалиста в команду.

Что еще? Думаю что надо как то договорится о подаче материала. Здесь, как и в первой статье, я рассмотрю конкретный пример из своей практики, который, как мне кажется, максимально точно иллюстрирует специфику работу данного специалиста. Как и раньше, в заключении, попробую ответить на следующие вопросы: кто такой Системный Архитектор, какими навыками должен обладать и т.д. Поехали? 

И последнее, думаю, надо представится. Меня зовут Владимир Воловиков. Опыт работы в сфере разработки программного обеспечения более 20 лет. В должности Системного архитектора и Программного архитектора, в общей сложности, более пяти лет. Имею четыре международных сертификата. Текущее место моей работы Системный архитектор, Банк ВТБ. 

Читать далее
Всего голосов 15: ↑14 и ↓1 +13
Комментарии 9

Разбираемся в сортах реактивности

Время на прочтение 27 мин
Количество просмотров 35K

Здравствуйте, меня зовут Дмитрий Карловский и я… прилетел к вам на турбо-реактивном самолёте. Основная суть реактивного двигателя изображена на картинке.



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


Это — текстовая расшифровка выступления на SECON.Weekend Frontend'21. Вы можете посмотреть видео запись, прочитать как статью, либо открыть в интерфейсе проведения презентаций.

Читать дальше →
Всего голосов 66: ↑58 и ↓8 +50
Комментарии 55

Как читать мысли и зачем это программистам

Время на прочтение 4 мин
Количество просмотров 12K

Приехали артисты в Японию, все написали в райдере, а про розетки забыли. А розетки там другие. Спрашивают «а есть переходники?» Японцы занервничали, забегали, начали боссам звонить. Прошло двадцать минут, возвращаются, говорят: «$2000 и мы снабдим все переходниками». Администратор плюнул, пошел в соседний супермаркет, купил переходники по $10 за штуку.

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

Читать далее
Всего голосов 39: ↑37 и ↓2 +35
Комментарии 29

Не работайте в плохих проектах

Время на прочтение 13 мин
Количество просмотров 99K

Частенько в дискуссиях на тему работы я встречаю тезисы о том, как плохо работать в том или ином проекте/компании/отрасли и т.д. И несмотря на то, что в отечественном IT в целом очень распространено нытье, многое из обсуждаемого действительно имеет место в реальности. Однако, спустя годы разработки, смены проектов, компаний и даже стека технологий, у меня выработалось понимание проблемы и ее решения с другого ракурса. Об этом и поговорим.


Читать дальше →
Всего голосов 220: ↑197 и ↓23 +174
Комментарии 574

Почему программисты — отстой

Время на прочтение 6 мин
Количество просмотров 25K

Давным-давно я написал статью на тему «Почему компьютеры – отстой» (в итоге получившую названия «Компьютеры» и «Что не так с компьютерами» [в оригинале ссылка битая, поэтому копия из вэбархива — прим. переводчика] в двух других версиях, а оригинальное название так и не вышло в свет). Статья была достаточно длинной, но суть сводилась к идее, что компьютеры отстойны из-за того, что программисты создают дичайше сложные штуки, которые больше никто не в состоянии понять, и того, что сложность основана на еще большой сложности до тех пор, пока каждый аспект программы не станет неуправляемым.


image
КПДВ отсюда


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

Читать дальше →
Всего голосов 33: ↑18 и ↓15 +3
Комментарии 60

Представление объектами: трудности роста

Время на прочтение 8 мин
Количество просмотров 1.7K

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

Читать далее
Всего голосов 5: ↑5 и ↓0 +5
Комментарии 15

Темные века разработки программного обеспечения

Время на прочтение 12 мин
Количество просмотров 10K

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

Но ситуация не была безнадёжной.
Всего голосов 19: ↑17 и ↓2 +15
Комментарии 2

Хороший инженер, плохой инженер

Время на прочтение 3 мин
Количество просмотров 5.1K

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

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

Читать далее
Всего голосов 27: ↑22 и ↓5 +17
Комментарии 14

Кто такой техлид и как с ним обращаться

Время на прочтение 7 мин
Количество просмотров 15K

Всем привет! Сегодня в гостях у нас Олег Мельник — Technical Lead в компании Proxify, а также преподаватель в OTUS.

Поговорили с Олегом про такую роль у разработчиков как техлид.

Читать далее
Всего голосов 32: ↑31 и ↓1 +30
Комментарии 10

Типовые ошибки при подготовке публичного выступления

Время на прочтение 8 мин
Количество просмотров 7.8K

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

Читать далее
Всего голосов 25: ↑24 и ↓1 +23
Комментарии 4

Типовые ошибки при подготовке презентации

Время на прочтение 6 мин
Количество просмотров 6.6K

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

Читать далее
Всего голосов 19: ↑19 и ↓0 +19
Комментарии 10

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

Время на прочтение 13 мин
Количество просмотров 14K

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

Здесь я расскажу о некоторых ранее предложенных идеях и свяжу их с новыми предложениями. Я проведу некий мысленный эксперимент и постараюсь ответить на вопрос «Что мы могли бы сделать с асинхронным программированием в Rust, если бы нам дали полный карт-бланш?». 

Непродуманное внесение изменений в Rust может разрушить его. Поэтому всё нужно делать аккуратно, учитывая плюсы и минусы. Допускаю, что некоторые предложения могут вызвать негативную реакцию. Я отношусь к этому с пониманием и прошу читателя подойти к изучению этого материала максимально непредвзято.

Потоки vs Асинхронность


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

Например, этот echo server написан с использованием потоков. Он работает быстрее своей асинхронной версии — для случая, когда количество одновременных подключений не превышает 100.
Читать дальше →
Всего голосов 43: ↑41 и ↓2 +39
Комментарии 47

Rust — сохраняем безразмерные типы в статической памяти

Время на прочтение 10 мин
Количество просмотров 6.1K

Не так давно в качестве хобби решил погрузиться в изучение embedded разработки на Rust и через какое-то время мне захотелось сделать себе логгер, который бы просто писал логи через UART, но который бы при этом не знал какая конкретно реализация используется. И вот тут я быстро осознал, именно в этом конкретном случае я не могу полагаться на статический полиморфизм и мономорфизацию, ведь компилятор не знает сколько нужно памяти выделять под конкретную реализацию. Фактически это означает, что нам нужно как-то уметь сохранять типы, размер которых неизвестен на этапе компиляции, и такой способностью обладает тип Box и для решения этой проблемы как раз и возникла идея написать свой аналог типа Box, но который сохраняет обьект не в куче, а в предоставленном пользователем буфере.

Читать дальше
Всего голосов 26: ↑26 и ↓0 +26
Комментарии 14

Информация

В рейтинге
Не участвует
Откуда
Екатеринбург, Свердловская обл., Россия
Дата рождения
Зарегистрирован
Активность