User
В последнее время нам почти каждый день рассказывают в новостях, какие очередные вершины покорили языковые нейросетки, и почему они уже через месяц совершенно точно оставят лично вас без работы. При этом мало кто понимает — а как вообще нейросети вроде ChatGPT работают внутри? Так вот, устраивайтесь поудобнее: в этой статье мы наконец объясним всё так, чтобы понял даже шестилетний гуманитарий!
Этот материал представляет собой глубокое исследование всего, что связано с Redis. В частности — речь пойдёт о различных способах организации хранилищ Redis, о постоянном хранении данных, о форках процессов.
Наверное, в жизни разработчика, с бэкграундом геймера, возникает мысль о разработке собственного проекта, который точно реализует все детские хотелки и будет лучшим из лучших.
В моей голове подобный проект всегда выглядит, как несбыточная мечта, однако, на протяжении моей карьеры, где на данный момент я - Lead Full Stack Software Development Engineer, где Full Stack - это полный цикл разработки включающий Technical writing, QA, SDET, SDE, Architecture, BA, DBA, UI/UX и так далее, наконец-то сформировался концепт проекта мечты и, собственно, план по реализации, осталось дело за малым.
Привет, Хабр!
Сегодня я хотел бы рассказать о генерации идеального лабиринта - алгоритмом Эллера. Статья подойдёт всем любителям алгоритмов.
Если вы собрались плотно погрузиться в тему Doman Driven Design (DDD), о том как его применять, как использовать, для чего он нужен, и как с ним связаны Command and Query Responsibility Segregation (CQRS), Event Sourcing и другие термины из мира DDD то можно воспользоваться планом обучения, который последовательно погрузит вас в эти темы и поможет сориентироваться. Часть информации на русском, часть на английском языке, так как русскоязычных аналогов я не смог найти.
Мало просто сменить свою сферу работы на IT, желательно еще и стать хорошим разработчиком. Бывший тимлид и консультант Александр Усков рассказывает, как понять, что перед вами плохой разработчик и что с ним вообще можно делать
В этой статье мы разберем признаки слабых разработчиков, которые можно обнаружить на собеседовании, в ходе совместной работы или даже в процессе неформального разговора в курилке. Важное уточнение — все описанное в нашей статье не стоит рассматривать как чек-лист формальных правил. Это скорее некоторые закономерности, каждая из которых не является гарантией того, что перед вами — «плохой» разработчик. Но, если в одном человеке сочетаются несколько из них, то вероятность этого сильно увеличивается.
Для кого эта статья? Эта статья, также как и первая, рассчитана на людей, работающих в сфере ИТ. Для разработчиков, тестировщиков, менеджеров разного уровня, аналитиков и т.д. Для расширения кругозора, она также может быть полезна и всем остальным, просто, чтобы иметь представление о том, чем занимается Системный Архитектор. Пригодится материал и тем, кто планирует развитие своей профессиональной карьеры, и тем, кто выкладывает такого рода вакансию и ищет специалиста в команду.
Что еще? Думаю что надо как то договорится о подаче материала. Здесь, как и в первой статье, я рассмотрю конкретный пример из своей практики, который, как мне кажется, максимально точно иллюстрирует специфику работу данного специалиста. Как и раньше, в заключении, попробую ответить на следующие вопросы: кто такой Системный Архитектор, какими навыками должен обладать и т.д. Поехали?
И последнее, думаю, надо представится. Меня зовут Владимир Воловиков. Опыт работы в сфере разработки программного обеспечения более 20 лет. В должности Системного архитектора и Программного архитектора, в общей сложности, более пяти лет. Имею четыре международных сертификата. Текущее место моей работы Системный архитектор, Банк ВТБ.
Здравствуйте, меня зовут Дмитрий Карловский и я… прилетел к вам на турбо-реактивном самолёте. Основная суть реактивного двигателя изображена на картинке.
Тут, казалось бы, хаотичное взаимодействие между молекулами, приводит к тому, что улетающие молекулы опосредованно передают импульс корпусу двигателя. Что ж, давайте подумаем, как реактивные принципы решают или наоборот усугубляют проблемы в программировании. Сравним различные подходы к реактивному программированию. И вытащим на поверхность все их подводные камни.
Это — текстовая расшифровка выступления на SECON.Weekend Frontend'21. Вы можете посмотреть видео запись, прочитать как статью, либо открыть в интерфейсе проведения презентаций.
Приехали артисты в Японию, все написали в райдере, а про розетки забыли. А розетки там другие. Спрашивают «а есть переходники?» Японцы занервничали, забегали, начали боссам звонить. Прошло двадцать минут, возвращаются, говорят: «$2000 и мы снабдим все переходниками». Администратор плюнул, пошел в соседний супермаркет, купил переходники по $10 за штуку.
При чем тут программирование? Порой программисты точно так же реагируют на изменение требований. Кто мог подумать, что у артистов из Европы нет переходников? Как они посмели не отразить это в ТЗ райдере. Теперь еще месяц разработки, никак не меньше.
Частенько в дискуссиях на тему работы я встречаю тезисы о том, как плохо работать в том или ином проекте/компании/отрасли и т.д. И несмотря на то, что в отечественном IT в целом очень распространено нытье, многое из обсуждаемого действительно имеет место в реальности. Однако, спустя годы разработки, смены проектов, компаний и даже стека технологий, у меня выработалось понимание проблемы и ее решения с другого ракурса. Об этом и поговорим.
Давным-давно я написал статью на тему «Почему компьютеры – отстой» (в итоге получившую названия «Компьютеры» и «Что не так с компьютерами» [в оригинале ссылка битая, поэтому копия из вэбархива — прим. переводчика] в двух других версиях, а оригинальное название так и не вышло в свет). Статья была достаточно длинной, но суть сводилась к идее, что компьютеры отстойны из-за того, что программисты создают дичайше сложные штуки, которые больше никто не в состоянии понять, и того, что сложность основана на еще большой сложности до тех пор, пока каждый аспект программы не станет неуправляемым.
КПДВ отсюда
Чего я не знал тогда, так это почему программисты делают это. Было очевидно, что они делают это; но почему индустрия разработки программного обеспечения создает так много дикого, сложного и нечитаемого кода? Почему это продолжается даже после того, как, казалось бы, разработчики должны были извлечь урок из первого негативного опыта? Что заставило программистов не просто написать плохой код, а продолжать делать это снова и снова?
В этой небольшой заметке я хотел бы поделиться соображениями, которые возникли в процессе разбора одного нехитрого упражнения. У меня нет хороших выводов, но общее направление мысли состоит в том, что *эволюционный* рост системы приводит к своего рода локальному оптимуму архитектуры, выбираться из которого приходится ценой существенной перестройки устройства проекта.
Пару лет назад я работал в SaaS-компании, которая страдала от всех возможных проблем, связанных с разработкой программного обеспечения. Код был настолько сложным, что внесение простых изменений занимало месяцы. Все проектные задачи и границы проекта оценивались только руководителем. Разработчики не понимали, какую проблему они решают. А когда не знаешь, чего ждет заказчик, многое из того, что делаешь, оказывается бесполезным. Команда не знала, что предложить заказчику. Все были очень разочарованы...
В организациях, которые применяют каскадный процесс или команды работают разрозненно, работа обычно передается между командами. Например, бизнес-группа определяет и предоставляет требования, группа по архитектуре решения определяет решения и проекты, группа разработки или доставки реализует решения и так далее.
Как вы понимаете, из-за меньшего взаимодействия и сотрудничества между различными функциями желаемый результат может не быть достигнут, и обычно происходит доработка, потому что каждая команда сосредотачивается на своей собственной области и выполняет то, что от них просят.
Всем привет! Сегодня в гостях у нас Олег Мельник — Technical Lead в компании Proxify, а также преподаватель в OTUS.
Поговорили с Олегом про такую роль у разработчиков как техлид.
Всем привет! У меня снова статья про качество. Только на этот раз речь пойдет не про код, а про подготовку к публичному выступлению.
Привет! Представляю продолжение статьи о типовых ошибках, которые допускают инженеры при подготовке публичных выступлений. Сегодня поговорим о подготовке презентаций.
Не так давно в качестве хобби решил погрузиться в изучение embedded разработки на Rust и через какое-то время мне захотелось сделать себе логгер, который бы просто писал логи через UART, но который бы при этом не знал какая конкретно реализация используется. И вот тут я быстро осознал, именно в этом конкретном случае я не могу полагаться на статический полиморфизм и мономорфизацию, ведь компилятор не знает сколько нужно памяти выделять под конкретную реализацию. Фактически это означает, что нам нужно как-то уметь сохранять типы, размер которых неизвестен на этапе компиляции, и такой способностью обладает тип Box и для решения этой проблемы как раз и возникла идея написать свой аналог типа Box, но который сохраняет обьект не в куче, а в предоставленном пользователем буфере.