Веб разработчик это – Веб-разработчик: курсы по веб-разработке, обучение на WEB-разработчика с нуля | GeekBrains — образовательный портал | GeekBrains

Содержание

10 вещей, которые вы должны знать как веб-разработчик / Habr

Привет, Хабр! Представляю вашему вниманию перевод статьи «10 Things You Should Know As a Web Developer» автора Anuupadhyay.

Написание тысячи строк кода и превращение в веб-сайт — одна из творческих и сложных вещей для веб-разработчиков. Если вы в этом деле новичок, увидели множество красивых веб-сайтов и подумали попробовать силы в этом, нам необходимо открыть глаза и рассказать о некоторых вещах, нужных веб-разработчику. Создание веб-сайта, который привлекает внимание пользователей, — это не только изучение различных языков программирования, это также изучение других концепций, таких как DevTools, форматы данных, тестирование, API-интерфейсы, аутентификация и многое другое. Здесь рассказывается о некоторых вещах, которыми должен овладеть веб-разработчик.

1. HTML / CSS / JS


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

CSS также используется в веб-интерфейсе, который определяет стиль, дизайн, макет и то, как элементы HTML должны отображаться на экране.

В настоящее время Javascript пользуется большим спросом и в отвечает за то, чтобы сделать ваши HTML-страницы динамичными. Javascript также поставляется с различными языками, такими как PHP, Python, ASP.Net, чтобы сделать ваш сайт более интерактивным. Если вы собираетесь специализироваться на Javascript, таком как MEAN Stack или MERN stack, вам следует  углубиться в этот язык, потому что он будет вашим внешним и внутренним языком.

2. Git и Github


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

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

3. Development Tools


Вы можете сделать много вещей, используя Development Tools, такие как отладка, редактирование элементов HTML, редактирование свойств CSS, проверка устройства, отслеживание ошибок JavaScript и т. д. Каждый разработчик должен знать об использовании различных вкладок (элементов, консоли, сети и многое другое) В DevTools, чтобы сделать их работу проще и быстрее. В зависимости браузера можно использовать любые DevTools, такие как Chrome DevTools, Firefox DevTools или другой браузер, который используете. Люди предпочитают использовать Chrome DevTools для разработки, тестирования и отладки веб-приложения, но опять-таки это выбор разработчика, какой браузер используется для разработки веб-сайта.

4. API (интерфейс прикладного программирования)


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

Рекомендуется узнать об использовании API-интерфейсов Rest, методов HTTP-запросов (GET, POST, PUT, PATCH и DELETE), создании API-интерфейсов Rest, операции CRUD (Create, Read, Update, Delete), другой код состояния, формат данных (JSON, HTML или XML), используемый в запросе и т. д.

5. Аутентификация


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

Существует множество способов реализации аутентификации для пользователей, и это зависит от того, какой язык программирования или технология используется. Если используется React на веб-интерфейсе и Node с Express в серверной части, может использоваться JWT (JSON Web Tokens) для аутентификации, если вы используете Php, вам придется работать с сессией и файлами cookie, также можете использовать такие сторонние организации, как Google или Twitter для входа. Таким образом, есть несколько режимов работы с аутентификацией, но для веб-разработки важно изучить и внедрить ее.

6. MVC (модель, вид, контроллер)


MVC — это шаблон проектирования, который экономит много времени разработчиков, разделяя приложение на три разных раздела. Работа с шаблоном MVC делает разработку быстрее и проще. Многие высокоуровневые фреймворки, такие как Laravel, Django (на основе MVT, близких к MVC), Angular созданы на основе паттернов MVC. В MVC модель связана с взаимодействием с базой данных, представление отвечает за все, что пользователь видит на экране, а контроллер выступает в качестве интерфейса между моделью и представлением. Изучение MVC поможет легко понять основы для любого языка программирования.

7. Языки программирования


Компьютеры не понимают человеческие языки, и поэтому необходимо общаться с системой на языках программирования. В веб-разработке не только языки программирования обязательны для изучения, но и алгоритмы, которые вы можете применять, используя широкий спектр языков программирования. Веб-разработчики используют различные языки, такие как PHP, Python, Java, Ruby и, в последнее время, Javascript, который составляет им конкуренцию. Как веб-разработчик, вы должны знать хотя бы один язык программирования для создания веб-приложения.

8. Поиск и решение проблем


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

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

9. Написание тестов


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

10. DevOps и развертывание


И последнее, но не менее важное: как веб-разработчик, вы должны обладать знаниями по обслуживанию, масштабированию, миграции и развертыванию кода на различных платформах, таких как Google Cloud, AWS, Heroku, Netlify и т. д. Существует множество вариантов, поэтому потратьте некоторое время на изучение этих платформ, как эти службы работают и как развернуть или поддерживать код на этих платформах.

9 признаков того, что не стоит нанимать этого Веб-разработчика / Habr

В феврале 2008 года я написал статью 9 признаков того, что не стоит нанимать этого Веб-разработчика. Этот пост «взорвал» интернет, попав на главную Digg и Reddit, и даже был выбран Кевином Роузом для одного из эпизодов Diggnation. Я был невероятно горд этим постом, ведь он действительно адекватно отображал тип вебмастеров, которых не следовало нанимать.

С тех пор прошло много времени, но это всего лишь значит, что изменились качества, по которым мы оцениваем веб-разработчиков. Под катом список из 9 признаков того, что не стоит нанимать этого веб-разработчика.

Мобильные версии его сайтов работают только в WebKit


Мобильные устройства на iOS и Android занимают львиную долю рынка мобильных устройств и используют браузеры на основе Webkit, как и гибридные мобильные приложения под эти платформы. Это привело к тому, что разработчики используют только префиксы -webkit- в коде мобильных приложений, несмотря на то, что доля Opera, Mozilla и Internet Explorer в мобильном интернете растет. Это аналогично программированию только под IE во времена 4,5,6 Internet Explorer'а. В Mozilla для большинства CSS свойств префиксы убраны, поэтому все будет работать если вы используете стандартные правила CSS, но для самых новых свойств все же стоит использовать -moz-префиксы. Важно помнить, что на мобильных устройствах есть не только Webkit и релиз Firefox OS докажет это (если Firefox для Android еще не сделал этого).

Он — разработчик "{{ js библиотеки }}"


За последние несколько лет я провел десятки технических собеседований и достаточно быстро могу понять, знает ли кандидат JavaScript, или какую-то конкретную библиотеку, а это — очень большая разница. Я спрошу что-нибудь простое, например: «Как Вы получите все дочерние элементы данного элемента?». Будет не очень хорошо, если в ответ я услышу «я использую метод children()».

Он пишет весь код в одном файле


Библиотеки вроде RequireJs или CurlJS сделали загрузку модулей на JavaScript настолько простой, что больше ничего не может оправдать написание кода в одном файле. Это нормально если Ваш сайт использует совсем немного JavaScript'а, но во всех других случаях нет смысла создавать огромные .js файлы из-за лени или отсутствия опыта.

Его дизайн не отзывчивый


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

Он знает HTML5


Сегодня знать HTML5 — это тоже самое, что знать Web 2.0 несколько лет назад. HTML5 — это маркетинговый термин и пустые фразы о знании HTML5 — это знак, что разработчик не знает что это такое. Попросите того, кто утверждает, что знает HTML5 рассказать об определенных API, если затрудняется с ответом — не нанимайте его!

Не использует определение возможностей браузера


Любой опытный разработчик скажет Вам, что на использование данных из User Agent для определения возможностей браузера нельзя положиться, но еще хуже — не использовать проверку необходимого функционала в браузере, наивно полагая, что нужный функционал присутствует во всех браузерах. Это верно и для использования новых CSS свойств без префиксов. Такой веб-разработчик создаст Вам много проблем.

Он подключает ненужные библиотеки


JavaScript библиотеки и плагины крайне полезны, но очень часто чрезмерно используются. Если бы я получал доллар за каждый раз, когда я встречаю библиотеку jQuery на сайте, которая используется для простой анимации или несложного взаимодействия с DOM, я бы стал миллионером. Также я нередко встречаю библиотеку Modernizr, подключенную для проверки одного-единственного свойства браузера, хотя можно было просто использовать код для проверки одного этого свойства. Такие действия приводят к увеличению размера страницы и нагрузки.

Он все еще считает, что мобильная разработка — это только приложения для iOS


iPhone и iPad не были первыми мобильными устройствами, но они были первыми, набравшими популярность, поэтому в течении короткого отрезка времени они были единственными устройствами, о которых нужно было задумываться при разработке мобильных приложений. К сожалению, такой веб-разработчик все еще живет в прошлом, в то время как устройства на Android и Firefox OS становятся все более популярными.

Он не воспринимает всерьез мобильные приложения на HTML


Разработчик, которого Вы не хотите нанимать, все еще считает, что мобильные приложения, основанные на HTML — это несерьезно и PhoneGap — это единственное средство для их разработки. C появлением Firefox OS и множества других новых ОС, основанных на web, любое приложение, которое работает в браузере, будет работать в новых операционных системах. Поэтому негативное отношение к мобильным приложениям на основе HTML может сыграть против вас.

Несмотря на то, что определение плохого веб-разработчика изменилось за последние годы, Вы всегда легко узнаете его. Будьте настороже, такой «разработчик» легко создаст Вам массу проблем!

Зачем современную веб-разработку так усложнили? Часть 1 / Habr

Современная фронтенд-разработка оставляет полярные впечатления: одни её любят, другие презирают.

Я большая поклонница современной веб-разработки, хотя она мне напоминает некую «магию», со своими плюсами и минусами:

  • Когда вы поймёте, как использовать волшебные инструменты (babel! бандлеры! вотчеры! и так далее!), ваш рабочий процесс становится быстрым, мощным и восхитительным
  • Если вы не понимаете волшебные инструменты, всё ужасно запутанно
  • …и попытки освоить магию слишком часто неудачны, если вам кто-нибудь не поможет продраться через джунгли жаргона, преувеличений и устаревшей информации в интернете

Недавно мне пришлось объяснять «современные рабочие процессы веб-разработки» людям, далёким от этого, и…

Пришлось реально МНОГО объяснять!

Даже поверхностное объяснение оказывается довольно длинным. Но всё же попытаемся проследить эволюцию веб-разработки:

Часть 1: Как мы добрались со статических сайтов до babel




Начнём с «классической» веб-разработки, которая всем должна быть понятна.

В классической разработке мы непосредственно изменяем файлы HTML/CSS/JavaScript. Чтобы просмотреть результат изменений, открываем HTML-файл локально в браузере, а по мере разработки обновляем страницу.

Рабочий процесс


Рабочий процесс выглядит следующим образом:
  1. Редактируем HTML/CSS/JavaScript в текстовом редакторе, таком как Atom.
  2. Сохраняем файл в текстовом редакторе.
  3. Открываем или перезагружаем файл в браузере.


Редактируем JavaScript, сохраняем файл, обновляем страницу

Развёртывание


Когда вы хотите опубликовать свой сайт в интернете, то просто куда-нибудь загружаем эти файлы HTML/CSS/JavaScript.

С помощью сервиса типа Netlify вы можете просто перетащить папку с файлами, чтобы опубликовать страницу в интернете. Вот пример опубликованной страницы.


Если вы понимаете, как работает «классический» рабочий процесс, то можете сказать: чёрт, это действительно просто и удобно. Зачем вообще нужно было его изменять?! Почему современная веб-разработка настолько сложна?

Короткий ответ… Окей, два коротких ответа.

Два коротких ответа:

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

Чтобы понять инструментарий, мы должны понять проблемы современной веб-разработки. В этих статьях рассмотрим каждую из них по отдельности, начиная со старой проблемы веб-разработки, которая существовала в течение десятилетий:
До недавнего времени JavaScript и Web API имели множество ограничений (по множеству причин, которые мы опустим).

Вот некоторые из них:

  • Не было модулей
  • Не было констант
  • Не было промисов / async
  • Не было Array.includes() (!!)
  • Неуклюжий / отсутствующий синтаксис для многих общих примитивов (нет for-of, литералов шаблона, синтаксиса стрелочных функций, распаковки шаблона…)
  • (Web API) Бесчисленные операции DOM были бесполезно сложными (например, добавление/удаление имён классов, скрытие элементов, выбор элементов, удаление элементов…)

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

Отдельно: Какая разница между JavaScript и Web API?


Возможно, вы заметили, что выше я сказала «JavaScript и Web API». Это две разные вещи!

Когда вы пишете JavaScript для веб-страницы, любой вызов API, взаимодействующий с самой веб-страницей, представляет Web API (которые, так получилось, написаны на JavaScript), но это не часть языка JavaScript.

Примеры:

  • Web API: document и каждый method в document; window и каждый method в window; Event, XMLHttpRequest, fetch и т. д.
  • JavaScript: функции, const/let/var, массивы, Promise и т. д.

Например, если вы пишете сервер на Node.js, то пишете на JavaScript и можете использовать, например, промисы, но не можете использовать document.querySelector (и это не имеет смысла делать).
Ещё в 2006 году вышла библиотека jQuery, которая помогла обойти многие недостатки JavaScript и Web API.

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

Итак, по сути: всё это было технически возможно с использованием старого JavaScript и старых Web API, но процесс был очень раздражающим, утомительным и часто сложными для разработки. Поэтому вместо написания утомительного кода, например, для загрузки и обработки файла JSON, вы могли просто загрузить библиотеку jQuery и использовать отличные jQuery API.


Однако с 2006 года прошло много времени!

С тех пор JavaScript и Web API значительно улучшились, в том числе благодаря помощи от jQuery и других, показавших путь!

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

Возможно, вы слышали термин “ES6”. Он означает “ECMAScript 6” и относится к 6-й итерации ECMAScript. ECMAScript — это ещё одно название JavaScript. Просто в разговорной речи люди обычно используют “ECMAScript” для ссылки на саму спецификацию, а “JavaScript” — для ссылки на код.

(Кстати, ещё одна путаница и моя любимая мозоль: JavaScript не является реализацией/диалектом ECMAScript; это как называть “HTML” реализацией/диалектом «спецификаций HTML». В любом случае, это неправильно! Википедия, ты ошибаешься! JavaScript и ECMAScript — это одно и то же).

ES6 (выпущенный в 2015 году) примечателен тем, что добавляет много действительно приятных языковых функций в JavaScript, таких как const, модули и промисы (а ES8 представил мою любимую языковую функцию: async).

Параллельно и Web API значительно улучшились с 2006 года, с добавлением document.querySelector, fetch и мелочей вроде classList и hidden.

Поэтому вместо jQuery или других подобных библиотек в 2019 году мы можем, по большей части, просто напрямую использовать JavaScript и Web API.

…вроде того!


Когда выходит обновление языка JavaScript, браузеры также следует обновить для поддержки новых функций (то же верно и для Web API, но для простоты оставим только JavaScript).

Тем не менее, есть задержки между 1) определением новой функции в языке; 2) реализацией функции во всех браузерах; 3) обновлением браузеров у всех пользователей (а это может никогда не произойти).


Дилемма: писать на старом или последнем JavaScript? У обоих подходов есть плюсы и минусы (конкретный пример кода взят отсюда)

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

Эту конкретную дилемму решает Babel.

Babel — это компилятор JavaScript, который преобразует код JavaScript в… другой код JavaScript! В частности, он преобразует код JavaScript, написанный с использованием последней версии JavaScript, в эквивалентный код, написанный с использованием более старой версии JavaScript, которая поддерживается в гораздо большем количестве браузеров.


С Babel мы можем наслаждаться преимуществами кодирования на последнем JavaScript, не беспокоясь о совместимости браузеров

Оговорка: Babel не поддерживает Web API


Например, если вы используете fetch в своём JavaScript, то babel не предоставит резервной поддержки (она называется «полифиллинг»), потому что fetch — это Web API, а не часть самого JavaScript (эта проблема сейчас решается).

Таким образом, вам понадобится отдельное решение для полифиллинга Web API! Но мы вернёмся к этому в следующей статье.


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

Ниже приведён простейший рабочий процесс, который обычно не используется на практике (потому что более удобен бандлер вроде Parcel или webpack, но об этом позже).

Установка


  1. Установить* Babel
    (*Можете следовать инструкциям CLI, понимая, как работает npm. И эти инструкции рекомендуют устанавливать babel локально в качестве зависимости npm dev для каждого проекта, а не глобально на вашем компьютере)

Рабочий процесс разработки


  1. Разработайте свой сайт как обычную статическую веб-страницу.


    Пример: ванильный JavaScript размещается в каталоге src


Развёртывание


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

Вместо этого, вы хотите:

  1. Скомпилировать JavaScript с помощью babel, чтобы получить совместимый с браузером код:

    Это создаст новый, скомпилированный файл JavaScript в отдельной папке:


    Пример: Babel создаст второй “script.js”, уже с кроссбраузерной совместимостью

  2. Загрузить скомпилированный JavaScript в интернет вместе со своими HTML и CSS:

    Сайт будет* выглядеть и вести себя так же, как в режиме разработки, но пользователям будет выдаваться код, скомпилированный babel для всех браузеров.


    (*Надеюсь! Иногда есть различия в сборках Debug и Release, но это баги!)


Обратите внимание, что теперь у нас есть разделение между кодом «разработки» и кодом «релиза» (продакшна):

  • Код разработки: код, который вы пишете во время разработки веб-приложения.
  • Код продакшна: код, который требуется запускать при посещении пользователем.

Мы намеренно хотим разделить эти вещи, потому что:
  • Код разработки хорош для разработчиков, но плох для пользователей
  • Код продакшна хорош для пользователей, но плох для разработчиков

Во фронтенд-разработке не каждый использует или должен использовать Babel.

Но! Общая картина такова:

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

Это не просто распространённый, а часто ожидаемая картина для современной фронтенд-разработки.

(Обратите внимание, что наличие отдельных сборок Debug и Release является общим шаблоном в программной инженерии, а не чем-то особенным для веб-разработки. Но он особенно актуален для фронтенда, как по причине распространённости, так и из-за большой разницы во фронтенд-коде Debug/Release).

Краткий список технологий, где ожидается такое разделение между версиями разработки и продакшна:

  • модули npm
  • Любой препроцессор CSS
  • React/Vue/Angular/любой веб-фреймворк

Это общий шаблон, так что обратите на него внимание уже сейчас!
В следующей части нашего путешествия мы рассмотрим модули npm (что это такое и зачем) и бандлинг (что это и зачем), и как они усложняют рабочий процесс.

Как быстро подтянуть свой уровень веб-разработчика, чтобы соотвествовать требованиям работодателей?

Всем привет!

Моя профессиональная история такова. Чуть более чем 2 года назад я устроилась работать верстальщиком, не имея ни грамма опыта (проштудировала теорию по html/css, сверстала пару бесплатных макетов). Там меня, конечно, подучили основам верстки и научили работать в соответствии с целями компании (нас было всего 2 верстальщика: мой сэнсэй и я). Но поскольку это была не веб-студия, а контора со специфическими задачами, то, например, никаких cms (модных тогда) или, например, препроцессоров (модных сейчас... ну или уже не очень) мы не использовали. Спустя год я осталась единственным верстальщиком, я хорошо справлялась с возложенными на меня обязанностями и единолично верстала все для нашей системы (мы делали облачную ОС), попутно еще и являлась саппортом системы для пользователей, но это к делу отношения не имеет. Всякие новые фичи я не использовала: да, я читала хабр и всякие статеечки постоянно, была в курсе тенденций, что-то немного внедряла в проект (например, самая последняя версия нашей системы построена на флексах), но в целом, большинство из этого читалось и забывалось, поскольку не использовалось.

Суть вопроса такова. Я уже месяц там не работаю и этот же месяц нахожусь в ступоре. Я, конечно же, пытаюсь подыскать работу, пересматриваю каждый день вакансии (тысяча из ларца, одинаковы с лица) и то, что хотят от людей при названии вакансии "html-верстальщик" просто поражает. Всем подавай фрейморко-задрота, js-гуру, фронтэнд-мастера, и под мобильные, и под ретину, и под часы (наверное, тоже скоро станет требованием), при этом желательно еще дизайн дизайнить и юзабилити юзабилить. Я утрирую, но суть такова, что за время работы я не сверстала ни одного сайта (ну ладно, пару лендингов), я не умею юзать jQuery, я никогда не пользовалась less/sass/stylus и boostrap'ом, не верстала с помощью БЭМ, ничего не знаю о всех этих модных JS-фреймворках и тем более я не пишу на чистом JS-е... Я боюсь откликаться на какие бы то ни было вакансии, ибо удовлетворяю максимум 2-3 пунктам из списков, длинною в экран монитора. Я сижу и судорожно перечитываю статьи, уроки, зачем-то прошла все курсы на HTML Academy (хотя это было больше похоже на решение задач по знанию таблицы умножения), вообщем занимаюсь тут черти чем, преимущественно самоуничижением.

Да, я понимаю что все эти штуки не такие сложные и я абсолютно уверена, что обучусь всему со временем, но на данный момент у меня нет опыта использования всего этого офигенного многообразия.
Что мне делать? Сидеть учить это дома, тренируясь на коленке? Зная себя, я вряд ли освою что-то хорошо, делая это "в воздух". Я очень люблю читать теорию, писать конспектики - у меня уже толстенный ежедневник накопился, можно книгу издавать 🙂 Но это больше похоже на прокастинацию, реального опыта в разработке не прибавляет, как и возможности приписать что-то к резюме.
Идти наобум лишь бы взяли хоть куда? Но я очень не хочу попасть в ситуацию - еще пара лет "голой" верстки (html и css онли), а для "не только верстки" я, очевидно, еще "слабовата". Я правда хочу стать полноценным JS-разработчиком, а не фронтэнд-огрызком.
Начать фрилансить? Да, так я точно наберусь опыта, но факт взаимодействия с кучей разных людей меня напрягает, я в это все полезла только ради того, чтобы минимизировать общение с непонятными людьми.

И да, извините за длиннопост. Накопилось тут.

выбери себе приключение / Авито corporate blog / Habr

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

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

upd — немного дополнил текст до ката.


Предположим, что я и мой друг Валерка решили сделать стартап. Uber for X, или там еще что-нибудь в таком духе. Собрались в баре, обсудили эту идею, клёвая тема. Надо сделать. Три месяца не спали, не ели, не выходили из дома. Разрабатывали. Запустили и поняли, что это никому не нужно.

Печаль. Попробуем еще раз. На этот раз мы изучили рынок, посмотрели, какие потребности у пользователей, какие проблемы. Мы сделали какой-то прототип совсем на коленке, быстро и бесплатно за два вечера. Прототип взлетел. Круто, идем дальше.


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


Язык

По порядку. На каком языке писать? Можно взять модный функциональный: Haskell, Erlang, Lisp (очень модный среди дедушек старше 70). Либо очередного убийцу JS, который очень клевый, компилируется в JS, имеет все нужные фичи. Но скорее всего, нам некого будет нанимать через год, потому что очередной убийца JS не взлетит, и придется переучиваться заново или переписывать проект.

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

Еще варианты? Можно взять Perl, но тогда будет некого нанимать ещё вчера. Ещё?
Java. Java — норм. Как язык не очень, на мой субъективный взгляд, но JVM — отличная виртуальная машина, все ок, быстро работает, но железа все равно нужно много. А ещё пока мы на Java писали абстрактный билдер фабрики стратегий вместо того, чтобы делать фичи, пользователи ушли к конкурентам.

Ладно, у нас есть еще Python. В принципе, у него всё ок. Но мы запускаем приложение на Python, оно использует одно ядро из 56, в остальном… все ок. Либо можно взять что-то современное: Go, Rust, еще что-то. Но они слишком низкоуровневые, и мы просто долго делаем фичи… Какой-нибудь язык нам всё равно придется выбрать. Пусть в итоге это будет JS, сойдет.


База данных

База. JS без документной базы — деньги на ветер. У документных баз есть свои плюсы. Они позволяют нам быстро разрабатывать прототипы, не париться насчет схемы, колбасить данные туда-сюда. Плюсов много, минус один: каша из данных. Когда коллекций у нас становится десять, двадцать или сорок вместо трёх, когда мы без отсутствия схем пытаемся склеить из них что-то хорошее и удобоваримое, становится это делать все сложнее. Опять долго делаем фичи.

Ок, давайте возьмем реляционную базу. MySQL, PostgreSQL, или Oracle, если денег хватит. С реляционными базами можно однажды прийти на работу и обнаружить себя в аду из транзакций и хранимок. Это не обязательно произойдёт с нашим проектом. Но если произойдет, то эти хитросплетения логики будет невозможно тестировать. А ещё если вдруг мы достигнем вертикального предела нашего большого золотого сервера, на котором мы хостим базу, потом будет довольно сложно их разделять. Долго делаем фичи.

Ладно. Базу взяли какую-нибудь, бахнули перед ней ORM, чтобы проще было с одного SQL на другой переезжать. Когда-нибудь (spoiler: никогда).


Архитектура

Какую взять архитектуру? Ребята на Хабре пишут, что микросервисы – это клёво. Олег Бунин говорит: «берите микросервисы».

Если начать с микросервисов, то с восьмидесятипроцентной вероятностью границы у них будут неправильные, потому что не до конца продумали доменную модель и плохо поняли, где надо резать, а где не надо. Плюс все берут микросервисы, деплоят их пачками по всему своему кластеру, и через месяц возникает вопрос: «а как это всё теперь тестировать?». Сервисы уже работают в продакшене, а мы их не тестируем. Используя привычные методологии (пирамида тестирования, ручные интеграционные тесты, end-to-end тесты), тестировать микросервисы сложно. Поэтому мы долго делаем фичи.

Ок, тогда давайте бахнем монолит. Это самая правильная идея для стартапа. Очень долго можно жить с отличным монолитом и не иметь проблем. Но если мы решим сильно расширить команду, то надо быть осторожнее. Монолит нормально масштабируется, пока разработчиков 20, 30, 50. Дальше скорость доставки фич падает экспоненциально, а мы теряем пользователей.


Где запускать проект?

Это всё надо где-то запускать. 2018 год, самый логичный вариант сделать это в облаке. Запустишь не в облаке — пацаны засмеют. Но, во-первых, есть федеральный закон 152, значительно ограничивающий выбор облачных провайдеров, у которых можно хоститься. Во-вторых, очень легко приватный ключ от своего аккаунта на Amazon случайно закоммитить в Github, и кто-то обязательно придёт и потратит все ваши деньги. А если этого не произойдёт, то в какой-то момент вас разорят облачные тарифы.

Можно арендовать дата-центр. Может, это не так ресурсоэффективно изначально, но в долгосрочной перспективе, вероятно, обойдётся дешевле, чем хоститься в облаке. Но тут нужны люди, которые это будут поддерживать. По моему опыту, те, кто это любят и умеют делать, не очень любят общаться со всеми остальными, поэтому они организуются в отдел. А отдел – это сепаратизм. Я имею в виду то, что внутри команды админов будет легче обмениваться опытом, но в будущем это может работать не очень хорошо. Будут вопросы с приоритезацией задач от других коллег, с синхронизацией. Другие специалисты не будут знать, что происходит внутри отдела, который поддерживает наш дата-центр.
В общем, сепаратизм нам не подходит. Логично переходим к вопросу набора команды.



Разработка

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


  • токсичными пижонами, которые ничего не будут делать и создадут плохую атмосферу в коллективе,
  • либо идеалистами, выстраивающими по крупицам безукоризненную архитектуру, ставящими ORM перед базами, которые никогда менять не придется...

В итоге… да-да, долго делаем фичи. Еще вариант — взять обычных девчонок и ребят, которые просто будут писать код, делать фичи нормально. Но если взять много не очень опытных разработчиков с разным бэкграундом, они могут писать код в разном стиле, делать штуки по-разному, и при достаточном размере команды всем будет тесно, все будут у друг друга фигурные скобочки переставлять в пуллреквестах. Это не очень эффективно. Как это можно решить? Начальник может читать весь код. Я могу читать все пуллреквесты, а мой друг и ко-фаундер Валерка потом второй раз будет перечитывать (на всякий случай, мало ли). Понятно, это не масштабируется и все медленно делают фичи.

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

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


Quality Assurance

Можно сказать, что QA-специалисты нам не нужны. Многие так делают, это иногда работает. Но не все разработчики любят писать тесты. Их можно понять. И стоит их лучше мотивировать, чтобы тесты все-таки писали, но реальность жестока: unit-тесты ловят далеко не все баги. А если какой-то разработчик не любит писать тесты и все-таки начал их писать, то скорее всего это будут unit-тесты.

Плюс еще есть подходы, когда ты минимизируешь mean time between failures вместо mean time to recover. Mean time between failures — это когда QA специалист говорит: «не будем релизить, у меня чутье плохое, баги будут, давайте через две недели выкатим». А mean time to recover — это когда вы катите что-нибудь, сразу видите на метриках, что что-то сломалось, и через две минуты все откатили, пофиксили и все ок. Но чтобы можно было проект через две минуты откатить, надо всё покрыть нормальными метриками, а это не всегда тривиально. А если метрики в плачевном состоянии, и мы выкатим плохой релиз, мы можем узнать об этом после того, как все пользователи уйдут от нас к конкурентам.

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

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

Как это разрулить? Общаться с коллегами в кружках по интересам. Где-то это называют гильдиями, где-то — коммьюнити. Если мы масштабируем команду кроссфункциональными командами, чтобы они не замыкались в себе, мы просто организуем кружок любителей бэкенда, функциональных языков, секьюрити…


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

А ещё — всё это интересно. Интересно решать проблемы, которые уже кто-то решал, новые проблемы еще интереснее решать. Интересно делиться знаниями.

WEB-разработка: что это и зачем?

WEB-разработка — процедура создания WEB-приложения или WEB-сайта. Основными этапами этого процесса являются мероприятия (далее читайте в этой статье…)

WEB-разработка — процедура создания WEB-приложения или WEB-сайта. Основными этапами этого процесса являются такие мероприятия, как WEB-дизайн, вёрстка страниц сайта, WEB-программирование на стороне сервера и клиента, а также работы по конфигурированию WEB-сервера.

Основные этапы разработки WEB-сайта

В настоящее время имеют право жить несколько распространённых этапов в разработке WEB-сайта, как-то:

  • проектирование WEB-приложения или самого сайта, то есть сбор и последующий анализ всех требований, выработка технического задания, составление проекта интерфейсов;
  • выработка концепции сайта с учётом креатива;
  • разработка дизайнерской концепции интернет ресурса;
  • разработка макетов страниц сайта;
  • создание и выполнение FLASH-элементов и мультимедиа;
  • верстание шаблонов и страниц;
  • работы по программному обеспечению, как-то создание функциональных инструментов, или же интеграция в уже существующую систему управления содержимым, т.н. CMS;
  • размещение на сайте и оптимизация его текстовых материалов;
  • тестирование сайта и внесение, при необходимости, корректировок;
  • запуск созданного проекта на общественной площадке в сети интернет;
  • работы по обслуживанию уже действующего портала или его программной части.

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

Техническое задание (ТЗ)

Его разработку для WEB-специалистов выполняет, обычно, менеджер всего интернет-проекта. Ну, а работа с самим заказчиком начинается с заполнения брифа, где он излагает свои желания в отношении структуры сайта и его визуализации, уточняет ошибки и недоработки, в случае наличия, в прошлой версии WEB-сайта, приводя свои примеры, как у его конкурентов. На основании брифа, менеджер создаёт ТЗ, учитывая при этом, имеющиеся в наличии возможности дизайнерских и программных инструментов. Сам такой этап оканчивается лишь после утверждения ТЗ клиентом. Однако, следует заметить, что все этапы проекта WEB-сайта довольно сильно зависимы от множества различных факторов, как, например, величина объёма интернет-портала, его функциональность, а также задачи для которых предназначен создаваемый интернет-ресурс и многое-многое иное. Но, тем не менее, имеется и некоторое количество этапов, которые непременно присутствуют при планировании абсолютно любого будущего проекта.

Дизайн страниц WEB-сайта: основных и типовых

Любая работа по интернет-сайту начинается с создания его дизайна, обычно используя для этого графический редактор. WEB-дизайнер создаёт, обыкновенно, несколько таких вариантов, но в строгом соответствии с ТЗ. При этом, отдельно разрабатывается дизайн «Главной» страницы сайта, и далее - дизайн остальных типовых страниц, как-то, например: новости, статьи, о нас, каталог. Собственно, сам «дизайн» являет собой графический файл, как слоёный рисунок, включающий в себя более мелкие картинки в виде слоёв в общей картинке.

При этом специалист обязательно учитывает все ограничения для стандарта HTML, то есть не вырабатывает дизайн, который невозможно будет впоследствии реализовать стандартными HTML-средствами. Исключением является только лишь Flash-дизайн.

Количество самих эскизов и порядок их предъявления заказчику заранее оговариваются с менеджеров всего проекта, который выполняет контроль запланированных сроков. Ещё, также больших WEB-фирмах в процессе принимает участие и Арт-директор, контролирующий качество исполнения графики. Этот этап точно также, как и предыдущий, оканчивается его утверждением у заказчика.

Вёрстка страниц и шаблонов в HTML

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

Программирование

После проведённых, выше упомянутых мероприятий, готовые файла в формате HTML передаются в работы WEB-программисту. Разработка программного обеспечения интернет-сайта вполне может выполняться, как «с самого нуля», так и на основании системы CMS, зачастую так называемого «CMS-движка».

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

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

Тестирование, как заключительный этап WEB-разработки интернет-сайта

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

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

Размещение нового портала в Интернет-сети

Файлы разработанного WEB-сайта помещают на сервере, например, провайдера, где осуществляют необходимые настройки. Следует отметить, что таком этапе интернет-сайт ещё пока закрыт для широкого круга пользователей.

Наполнение сайта контентом и его публикация

Новый интернет-сайт наполняют контентом, то есть различными текстами, изображениями, файлами для скачки и тому подобным. Иногда сами тексты составляются копирайт-специалистом фирмы-разработчика сайта, иногда ими занимается сам клиент, нанимая автора со стороны. Такой вопрос решается ещё на стадии составления самого ТЗ, так как, если контент разрабатывается копирайтером разработчика, то это обязательно согласовывается с заказчиком одновременно с иными этапами реализуемого проекта.

SEO-оптимизация: внутренняя и внутренняя

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

Внешнее SEO, как правило сводится, к построению определённой структуры для входящих ссылок на новый сайт. В принципе – это и есть сама раскрутка нового портала и к созданию сайта внешняя оптимизация не имеет никакого отношения. Сама же SEO-оптимизация подразделяется на так называемые: «белую» и «чёрную», после проведения первой интернет-портал попадает в ТОП, а после проведения второй - в «бан» поисковых систем. Следует заметить, что «белая» оптимизация – это довольно длительный и трудоёмкий процесс, при котором стоимость его самого которого может превысить в разы материальные затраты на WEB-разработку самого сайта.

Окончательная сдача всего проекта

Заказчик ознакамливается с полностью готовым заказом и в случае, когда его всё полностью устраивает, то подписывают соответствующие документы, как-то Акт выполненных работ, о сдаче ему всего проекта. Кроме того, на таком этапе работы осуществляется ещё и обучение клиента или его представителя необходимым навыкам администрирования нового сайта.

Примечание:

Учтите, что WEB-дизайн разрабатываемого сайта непременно обязан привлекательно выглядеть при использовании пользователями различных браузеров, особенно это касается таких браузеров, как Chrome, Internet Explorer, Safari, Firefox и Opera.

Ранее Internet Explorer ver.6 как-то по-своему трактовал стандарты HTML, будучи отголоском старой войны за превосходство с Netscape, который будучи уже давно морально устаревшим создавал огромное количество проблем для WEB-дизайнеров. Многие такие разработчики даже предлагали инициативу, что полностью отказаться от верстания сайтов под Internet Explorer-6, но его присутствие в стандартной комплектации ОС Windows XP на множестве пользовательских ПК, заставило WEB-разработчиков тестировать свои продукты и в нём.

P.S.

Если Вы нуждаетесь в разработке для себя интернет-сайта и не знаете, как это сделать, то Вам поможет услуга Компании ООО «Компания Скай» - WEB-разработка, которая возможна и значительно дешевле по Акции, при заказе одновременно с последующим SEO-продвижением сайта.


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *