Часто доводится слышать, будто протокол HTTP прост. Естественно, чаще всего — от тех, кто не слишком поднаторел в обращении с ним и слабо представляет, как именно этот протокол реализован. Думаю, сам я тоже мыслил в таком ключе, когда ещё только начинал работать с HTTP.

К настоящему времени я уже без малого три десятка лет усердно пишу клиентский код, взаимодействующий с HTTP. Я участвую в работе IETF и приложил руку ко всем спецификациям HTTP, составленным примерно с 2008 года. Поэтому полагаю, что вполне имею право развёрнуто высказаться об этом протоколе. Протокол HTTP не прост. Далеко не прост. Даже если предположить, что те, кто отмечает его простоту, имеют в виду лишь HTTP/1.

Сидим с другом в машине. Скидываю ему в Телегу ссылку на сайт по продаже щёток стеклоочистителей.

— Попробуй найти здесь дворники для своего Пассата.

Друг переходит по ссылке, видит форму подбора щёток по автомобилю. Открывает выпадающий список с перечнем марок. Листает вниз.

— Блин, неудобно же! Volkswagen — в самом низу. А машина популярная. Могли бы, не знаю, поиск какой-нибудь сделать. Или вынести несколько популярных марок наверх.

Кстати, друг — профессиональный дизайнер интерфейсов. В общем, долистывает до конца списка, выбирает Volkswagen и попадает на шаг с выбором модели…

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

Для тех, кто устал от корпоративного театра, но все еще любит своё дело.

Статья о моей философии в ИТ и изрядно приправлена самоиронией.

Мы не в эпоху сёгунов, но ИТ — та же война: против глупости, выгорания и бессмысленных скрамов.

И причём здесь катана и JBL?

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

Давным-давно, когда Linux был ещё на ядре 2.6, а PHP5 был глотком свежего воздуха, я впервые заинтересовался миром веб-технологий. Читал учебники, статьи, зависал на форумах, но все равно мало мог понять как код, который я вижу на экране, превращается в волшебные сайты с кнопками, формами и анимациями. Узнал про LAMP и его аналоги для Windows, узнал, что, оказывается, есть хостинги, где такие сайты размещаются. Как только появился внешний интернет без трафика, я поспешил перенести свои локальные поделия во внешний мир, попутно узнав про замечательный протокол FTP. Просто мир волшебных открытий был для меня, особенно когда узнал, что не нужно писать свой форум с нуля, а можно использовать что-то из phpBB, vBulletin и других уже готовых движков.

И когда я много лет спустя переключился в мир .NET, перечисленные ранее умения сыграли со мной злую шутку – я долго не мог понять, как мне найти хостинг для .NET приложений. Почему все известные мне хостинги с лёгкостью предоставляли возможность развернуть PHP приложения, причём даже предлагая какие-то предустановленные версии CMS, но днём с огнём не сыщешь хостинг под .NET. Мое непонимание принципа развертывания приложений усугубляли статьи, которые предлагали их размещать в подходящих сервисах типа Heroku, Digital Ocean или Azure – ведь это так просто и дешево…

Поэтому предлагаю максимально подробно рассмотреть вопрос публикации .NET приложений в арендованном VPS.

Привет, меня зовут Марат Зимнуров, я тимлид в кросс-функциональной команде HR Admin Tech Авито. Тема функционального программирования не обделена вниманием — и все же тяжело найти действительно понятный и структурно изложенный разбор данного инструмента. Нет нормального гайда для старта — ни у нас, ни на Западе. Многие говорят про иммутабельность и монады, но путаются в основах. В статье разбираю, что такое функциональное программирование на самом деле и зачем оно нужно.

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

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

Разработка — это не только про код, но и про подходы. В этой статье я постарался собрать и объяснить ключевые принципы проектирования, которые часто упоминают в собеседованиях, в статьях на Medium и в комментариях на GitHub, такие, как SOLID, DRY, KISS, YAGNI, APO, BDUF, бритва Оккама.

📌 Что внутри:

1. Понятные объяснения без перегрузки теорией

2. Примеры на Java (но подойдут и другим разработчикам)

3. Иллюстрации и метафоры, чтобы не уснуть

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

Привет, Хабр! Меня зовут Данила, мне 21 год, и за последние 2,5 года я успел поработать в роли разработчика программного обеспечения для встраиваемых систем — в основном на базе STM32. В этой статье я хочу поделиться тем, как я вообще пришёл в эту сферу, с чего начинал, какие грабли собрал и какие выводы сделал по пути.

Несмотря на то, что сам я ушел из большого ООП¹ более десяти лет назад, причем, надеюсь, навсегда, я всегда крайне вяло и неохотно участвую в баталиях тупоконечников и остроконечников: я абсолютно убежден, что для разных типов задач лучше подходят разные инструменты, и выхолощенное ФП заставит всех вокруг создавать тонны никому не нужного бойлерплейта для тривиального круда, а кристальное ООП — воткнет все возможные палки в колёса при реализации бизнес-процессов. Любой из современных языков программирования позволяет смешивать эти подходы, а микросервисная архитектура — даже гостеприимно приютит несколько языков и сред под одной крышей.

Тем не менее, хотя я никогда не считал себя евангелистом функционального подхода, и уж, тем более, не примыкал к стану воинствующих пуристов, меня постоянно свербил вопрос: что же все-таки не так с ООП, если лично мне быстрее, проще и понятнее — реализовывать свои проекты на функциональном эликсире?

И вот, наконец, меня озарило. Объектная модель всем хороша в однопоточной среде. Даже банальная асинхронность приносит кучу совершенно нерелевантных проблем: мьютексы любого сорта — это порождение дьявола. В игрушечных примерах из книжек они езе как-то работают, но действительно _многопоточный_ код на них написать фактически нереально. Среда, которая буквально приглашает разработчика ошибиться и разрушить тотальность функций потенциальным дедлоком — не должна иметь права на существование в принципе.

Если ты пишешь Dockerfile, скорее всего, он работает. Но вопрос не в том, работает ли. Вопрос в другом: будет ли он работать через неделю, на другом сервере, в CI/CD, на чужом железе — и будет ли это безопасно?

Забудьте о том, что Docker — это некий таинственный инструмент исключительно для DevOps-инженеров. В современном мире разработки Docker стал таким же незаменимым швейцарским ножом, как Git или ваш любимый редактор кода. Он позволяет любому разработчику писать код, который будет одинаково работать на машине коллеги, на тестовом стенде и в продакшене, забыв о кошмаре "а у меня на машине все работает". Если вы еще не погрузились в мир контейнеризации или вам нужен удобный источник команд, эта статья — ваш экспресс-билет.

При подготовке специалиста в области проектирования Информационных систем, важно учитывать конъектуру применения навыков в дальнейшем. Это может быть либо роль «Проектировщик» в каком‑то из проектов, либо постоянная профессия «Проектировщик ИТ‑продуктов».

DeepSeek 1.5B — маленький, но шустрый собрат больших языковых моделей. Работает локально, не требует железа на киловатт.

Внутри — инструкция по установке, настройке и запуску DeepSeek 1.5B на Ubuntu 24.04 с Ollama и Open WebUI.

Здравствуйте.

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

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

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

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

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

Хочу начать с личной предыстории. Давным‑давно, как и многие из вас, я читал умные книжки: «Чистый код» и «Чистая архитектура» Роберта Мартина, «Совершенный код» Стива Макконнелла и другие.

Также не обошли меня и классические принципы проектирования — SOLID, KISS, DRY — и, думаю, каждый читатель добавит сюда свои.

Безусловно, это всё важные и фундаментальные вещи.

Но однажды на горизонте появилось DDD — предметно‑ориентированное проектирование в изложении Эрика Эванса. Именно его «синяя книга» стала культовой и задала язык для архитектурного мышления.

Позже я открыл и «красную книгу» Вона Вернона, где DDD уже рассматривался с точки зрения практической имплементации: архитектура, код, реальные подходы в проектах.

Читая Эванса, рассматривая его диаграммы классов и примеры кода, я всё думал: как он это делает?

Самым большим открытием для меня стало то, что книга DDD хоть и показывает стратегические и тактические приёмы — агрегаты, объекты‑значения, спецификации, фабрики и т. д. — но не учит проектировать саму предметную область.

Складывалось ощущение, что мы это уже откуда‑то должны были знать. А откуда — остаётся загадкой.