На первый взгляд история и последующая эволюции серверов выглядит предельно просто. Ее исходные вехи: 1964 год — создание мэйнфрейма IBM System/360, каковой в числе прочего был сервером для его интерактивных консолей и прочих периферийных устройств, то есть сервером в «железе»;1969 год — сервер как инструмент в языке программирования DEL, то есть сервер в ипостаси «софта»; 1991-92 годы — первый веб-сервер глобальной сети, с одной стороны виртуальный «софт», написанный для обеспечения пользователя веб-контентом, с другой — вполне «железная» рабочая станция, даже с табличкой «Эта машина — сервер. Не выключайте ее».

Но все намного интереснее...

Привет. Я Катя. Я пишу фронтенд в Яндекс.Деньгах.

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

В этой статье я расскажу, что мы разрабатываем, как оптимизируем рабочие процессы и зачем развивать свои soft skills. На подходе вторая часть — она будет технической. В ней подробно расскажу про стек, почему их два и как мы дружили БЭМ с React (спойлер: будет много кода). Поехали!

upd. Вторая часть вышла.

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

Давайте разберёмся в отличиях подходов и попробуем сформулировать один общий вместо трёх.

Хей народ, пристегните ремни и держитесь покрепче, ибо наступил действительно волнительный момент: вам предстоит разобраться в тонкостях чрезвычайно интересных временных функций CSS!

1. Зачем нужен этот инструмент?
2. Какие задачи он выполняет?

Здравствуйте, меня зовут Александр Зеленин, и я веб-разработчик.
Многократно я слышал мнение, что верстка — удел начинающих frontend’еров. Хотя фактически это важнейшая часть любого (почти) веб-проекта. Это то, что пользователи видят в первую очередь. На текущий момент качественная вёрстка (особенно проектирование блоков) в крупном проекте требует большого количества различных навыков.

В данной статье представляю схему развития верстальщика

[большая по клику]
Само собой, это не всеобъемлющая и единственно верная схема. Есть ещё целая гора связанных навыков, релевантных технологий и так далее. Градация является субъективной.

Зачем использовать в вёрстке компонентный подход? Разбираемся, как и зачем верстать интерфейсы, используя этот подход, какие параметры и проблемы важно учесть. Разберём азы, забежим вперёд и подробно погрузимся в тему. Кстати, эта статья написана на основе одного из уроков курса «Профессиональная вёрстка на HTML и CSS» Яндекс Практикума. 

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

Сложно представить себе разработку на JS без вывода информации в консоль. Говоря метафорически, console.log() — лекарство от большинства болезней кода.

Отладка — почти как расследование преступления, где главный преступник тоже вы — Филипе Фортес

Но помимо повсеместно используемой функции console.log(), есть ещё много инструментов, позволяющий сильно упростить процесс. Давайте разберём некоторые из них на простых примерах.

Что делает разработчик, если ему нужно раскрасить кнопку в красный цвет? Ищет в npm пакет, окрашивающий кнопки в красный цвет

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

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

— Не понимаю, почему люди так восхищаются этим Карузо? Косноязычен, гугнив, поёт — ничего не разберешь!
— А вы слышали, как поёт Карузо?
— Да, мне тут кое-что из его репертуара Рабинович напел по телефону.

Детектив по материалам IT. Часть первая

Я осознаю, что писать очередную статью на тему Модель-Вид-Контроллер это глупо и вредно для «кармы». Однако с этим «паттерном» у меня слишком личные отношения – проваленный проект, полгода жизни и тяжелой работы «в корзину».

Проект мы переписали, уже без MVC, просто руководствуясь принципами – код перестал быть похож на клубок спагетти и сократился наполовину (об этом позже, в обещанной статье про то, как мы применяли «принципы» в своем проекте). Но хотелось понять, что же мы сделали не так, в чем была ошибка? И в течении долгого времени изучалось все, что содержало аббревиатуру MVC. До тех пор пока не встретились исходные работы от создателя – Трюгве Реенскауга…

И тогда все встало на свои места. Оказалось что фактически на основе принципов мы пере-изобретали «original MVC». А то, что зачастую преподносится как MVC, не имеет к нему никакого отношения… впрочем также как и к хорошей архитектуре. И судя по тому сколько людей пишет о несостоятельности «классического MVC», спорит о нем и изобретает его всевозможные модификации, не одни мы столкнулись с этой проблемой.

Более 30 лет собранные в MVC идеи и решения остаются наиболее значимыми для разработки пользовательских интерфейсов. Но как ни странно, несмотря на существующую путаницу и обилие противоречивых трактовок, разработчики продолжают довольствоваться информацией «из вторых рук», черпая знания о MVC из википедии, небольших статей в интернете и фреймворков для разработки веб-приложений. Самые «продвинутые» читают Мартина Фаулера. И почему-то почти никто не обращается к первоисточникам. Вот этот пробел и хотелось бы заполнить. И заодно развеять некоторые мифы.