Дорога длинна и трудна, но интересна и полезна!

Статья задумывалась как практическое руководство для желающих стать профессиональным веб-разработчиком. Я уже более 20 лет пишу код для веба. Я ежедневно работаю с веб-разработчиками и помогаю им. В статье я опишу, что вам нужно выучить, когда вам нужно это выучить и где взять информацию (чаще всего даже бесплатно). Затем я дам совет по получению реального опыта, и что самое важное – по получению денег за написание кода.

По статье разбросано множество ссылок на бесплатные и важные ресурсы. Для простоты я собрал их в PDF и разбил по категориям. Мне не платят за упоминания сайтов, ссылки на которые я привёл – я всего лишь хочу порекомендовать вам лучшие ресурсы, чтобы помочь вам достичь вашей цели.

Что нужно помнить:

1. Статью разрешается пролистывать

Руководство может помочь вам вне зависимости от вашего положения на дороге к профессиональной разработке. Прокрутите его к тому заголовку, который лучше всего описывает ваше сегодняшнее положение, и читайте оттуда. Если вы только начали этот путь, или пока размышляете об этом – последуйте совету Короля из «Алисы в стране чудес»:

Начните с начала, и продолжайте, пока не дойдёте до конца; и там уже остановитесь.
Читать дальше →

Привет, Хабр! Мы в компании PayOnline, которая занимается организацией платежей на сайтах и в мобильных приложениях, решили сделать перевод интересного аналитического материала – глобального опроса среди разработчиков за 2016 год, проведенного сайтом Stack Overflow. Чтобы не утомлять вас чтением действительно объемного исследования, мы выбрали самые интересные, на наш взгляд, слайды.


Общая информация

Каждые 8 секунд (или около того) кто-то из разработчиков публикует свой вопрос на Stack Overflow. В этом же году настал черед Stack Overflow: более 56 тысяч разработчиков из 173 стран ответили на задаваемые вопросы.

Всего им было задано 45 вопросов. Если вкратце, то получилась следующая картина:

Разработчики обожают Rust. Даже разработчики бэкенда знают JavaScript. Только 7% разработчиков считают себя «настоящими рок-звездами». Большинство разработчиков предпочитает собак кошкам (за исключением программистов из Германии).
Читать дальше →

Как известно, в следующем январе сервис Parse будет закрыт. Большинство разработчиков ищут альтернативу для этого сервиса. В одном из проектов guthub собралось достаточно много альтернатив, со ссылками и описанием. Перед вами — перевод этой страницы.

Часть 1: универсальные сервисы

Провайдеры, предоставляющие информацию в реальном времени, помечены (*).

AnyPresence MBaaS (Mobile backend as a service). Упрощает процесс создания мобильных приложений предприятия, работающих на разных устройствах, не ущемляя гибкость средств, доступных разработчику. Легок в использовании даже для неопытных пользователей. Опытные разработчики получают доступ к исходникам всех компонентов.

ApiOmat позволяет процессам предприятия работать как мобильным приложениям. Мобилизует сложные бизнес-структуры и процессы путём объединения существующих IT-систем с мобильными приложениями и устройствами. Его можно устанавливать прямо в дата-центре компании, что позволит работникам выполнять свою работу через приложения вне зависимости от их местонахождения.

Appcelerator Arrow (*) Состоит из двух основных компонентов, Builder и Cloud. Arrow Builder позволяет быстро создавать API, модели данных и соединители данных как через мастер настройки, так и через написание кода. Arrow Cloud – это эластичный облачный сервис, где выполняются API и происходит анализ их использования, плюс обеспечивается работа двух десятков смежных сервисов (гео, хранение фотографий и т.п.) с использованием ArrowDB

Appery.io Интегрированные сервисы MBaaS – чтобы разработчики могли сконцентрироваться на приложениях, не отвлекаясь на инфраструктуру.
Читать дальше →

Верстка современных web-проектов – это сложно, долго и дорого. Казалось бы, с переходом IE на автоматические обновления, HTML5, окончанием поддержки Win XP все мы должны зажить в сказочной стране с пони и радугой. Почему легче не стало?

• HTML5 и CSS3 подарили вебу возможность создавать UI, почти не уступающий по сложности и отзывчивости desktop-приложениям. Ничто не дается просто так, HTML, CSS и JS стало в разы больше. Раньше нам хватало трех файлов: styles.css, stupid-ie-must-die.css, scripts.js. Сейчас количество скриптов, стилей, загружаемых шрифтов, картинок измеряется десятками и сотнями. Появилась необходимость в минификации, ускорении рендеринга и организации всего этого барахла в файловой системе.
• Сайты постепенно перестали быть набором связанных гипертекстовых страничек и стали web-приложениями. Если раньше для многих сайтов достаточно было сверстать «главную» и «внутреннюю» страницы, то сейчас все совсем не так просто. Количество дизайн макетов легко достигает десятков и сотен.
• Мы все наслушались про лендинг-пейдж, a/b-тестирование и многократное увеличение конверсии за «просто-так». Оставим за бортом вопрос об эффективности этих методик. Дизайн начали переделывать часто – это факт. Известно, что внесение изменений и поддержка – гораздо дороже и сложнее, чем разработка.
• Появились мобильные устройства и необходимость в адаптивном дизайне. Тестировать стало сложнее и дольше. Цикл исправления найденных при тестировании багов стал дольше. Тестирование UI почти не поддается автоматизации, с ростом функционала время на регрессионное тестирование неуклонно растет.
• Усложнилась интеграция с backend-кодом, появилась необходимость делать это гораздо чаще.

Все это заставляет задуматься об оптимизации работы с фронтэндом.

Хочется:

• Уменьшить время и количество интеграционных работ («натягивание» сверстанного макета на серверную технологию)
• Повысить повторное использование html, css и js, уменьшить количество соответствующего кода
• Снизить время на модификацию существующего кода
• Уменьшить количество ошибок при модификации, особенно регрессии
• Научиться создавать и верстать адаптивный дизайн эффективно

Читать дальше →

При подготовке материала по Symfony Form я решил уделить некоторое внимание теоретической части по работе с формами со стороны клиента – что они из себя представляют, как ведут себя браузеры при отправке, в каком формате путешествуют, в каком виде поступают на сервер.

Вводная часть несколько растянулась и в итоге вылилась в отдельную небольшую статью, которая, по моему мнению, может быть интересна и другим бэкенд-разработчикам (не только PHP или Symfony).
Читать дальше →