Результати пошуку за запитом: Видеокурс c
Основи AngularJS на практиці
Автор: Редакция ITVDN
Введение
AngularJS – фреймворк-библиотека Javascript, разработанная для создания одностраничных приложений на основе MVC (Model-View-Controller) шаблона.
Будем осваивать данную технологию на практике.
Создадим HTML страничку со стандартной структурой. Далее нам нужно преобразовать ее в одностраничное приложение. Для этого подключим AngularJS к своей странице, добавив в
тег с данным кодом:
<script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.3.14/angular.min.js">
script>
Следующим шагом мы явно укажем на то, что наша страница является AngularJS приложением. Нужно добавить ng-app директиву, которой мы обозначим корневой элемент приложения. Зачастую таким элементом выступает тег или же тег . Добавим эту директиву к :
<!DOCTYPE html>
<html ng-app="">
<head>
<title>title>
<meta charset="utf-8">
<script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.3.14/angular.min.js">
script>
head>
<body>
body>
html>
Проверим, все ли работает, добавив небольшое выражение для подсчета произведения чисел 123 и 45. В AngularJs все выражения записываются в двойных скобках. Добавим в параграф со следующим содержимым:
<p>Результат произведение чисел 123 и 45 равен : {{ 123 * 45 }}p>
Запустим в браузере:
Теперь у нас есть готовый шаблон приложения, который мы будем использовать во всех последующих примерах.
AngularJS позволяет разработчику легко взаимодействовать с пользовательским вводом. Для этого есть соответствующая директива ng-model, которая связывает значения HTML элементов контроля (teaxtarea, input etc.) с приложением. Использовать эти данные поможет директива ng-bind, добавив эти данные во View (элемент MVC) и отобразив их на странице.
Применим полученные знания на практике. В созданный ранее шаблон добавим поле для ввода <input> с директивой ng-model и параграф для вывода данных c директивой ng-bind.
Код странички:
<!DOCTYPE html>
<html ng-app="">
<head>
<title>title>
<meta charset="utf-8">
<script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.3.14/angular.min.js">
script>
head>
<body>
<p>Ввведте свое имя:p>
<input type="text" ng-model="yourName">
<p>Здравствуй, <span ng-bind="yourName">span>p>
body>
html>
Откроем в браузере:
Теперь попробуйте ввести свое имя в поле для ввода.
Давайте добавим в данный пример дефолтное значение имени, к примеру Анна. Сделаем это, конечно же, с помощью директивы ng-init, которая позволяет инициализировать любую переменную AngularJS приложения.
В строку добавим директиву ng-init.
<input type="text" ng-model="yourName" ng-init="yourName='Aнна'">
Посмотрим изменения в браузере:
Теперь мы имеем значение по дефолту – Анна, но все так же можем изменять его:
Вывод данных в этом примере можно сделать еще одним способом, а именно, использовав выражение. Заменим на {{yourName}}.
<p>Здравствуй, {{ yourName }}p>
Открыв страницу, мы не увидим абсолютно никаких изменений, а все потому, что выражения в AngularJS связывают данные со страничкой точно так же, как и ng-bind директива.
Как упоминалось в статье ранее, AngularJS строит приложения на основе MVC. Часть модель – представление (Model - View) определяется с помощью директивы ng-app. Контроллер в свою очередь определяется директивой ng-controller.
Рассмотрим пример с использованием контроллера страницы.
Создадим страничку со списком гостей, которых Вы пригласите на свой день рождения.
К созданному ранее шаблону добавим контроллер, а так же установим имя для приложения. В тег внесем следующие изменения:
<html ng-app="firstApp" ng-controller="firstController">
Далее добавим с типом text для введения имени гостя и еще один с типом submit для добавления гостя в список. Также добавим
с полем для вывода списка и чекбоксом с типом checkbox для того, чтобы можно было удалять тех, кто не придет на ваш праздник. В данный
добавим директиву ng-repeat, отвечающую за повторение данных в обозначенном контейнере.
<!DOCTYPE html>
<html>
<head>
<title>title>
<meta type="utf-8">
<script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.3.14/angular.min.js">script>
head>
<body ng-app="firsApp" ng-controller="firstController">
<h2>Мои гости:h2>
<form ng-submit="addGuest()">
<input type="text" ng-model="guestsInput" size="50" placeholder="Введите имя гостя">
<input type="submit" value="Добавить гостя">
form>
br>
<div ng-repeat="guest in listOfGests">
<input type="checkbox" ng-model="guest.come"> <span ng-bind="guest.guestName">span>
div>
<p><button ng-click="remove()">Удалить гостя button>p>
body>
html>
Осталось добавить скрипт, который будет содержать функции для работы с элементами нашего приложения. Замечу, что все функции будут расположены в контроллере приложения.
Скопируйте и добавьте после закрывающегося тега параграфа с кнопкой
<p><button ng-click="remove()">Удалить гостя button>p>
следующий код:
<script>
var app = angular.module('firsApp', []);
app.controller('firstController', function($scope) {
$scope.listOfGests = [{guestName:'Я любимый', come:false}];
var countOfGuests = 1;
$scope.addGuest = function() {
$scope.listOfGests.push({guestName:$scope.guestsInput, come:false});
$scope.guestsInput = "";
countOfGuests++;
checkNumberOfGuests();
};
$scope.remove = function() {
var oldGuests = $scope.listOfGests;
$scope.listOfGests = [];
angular.forEach(oldGuests, function(guest) {
if (!guest.come) $scope.listOfGests.push(guest);
countOfGuests--;
});
checkNumberOfGuests()
};
function checkNumberOfGuests(){
if(countOfGuests <= 2){
alert("Маленькая вечеринка тоже не плохо! Не печалься! Лучших друзей не бывает много!");
}else if(countOfGuests >= 9){
alert("Праздник?! ВЕЧЕРИНИЩЕ!");
}else{
alert("Узкий круг самых близких, это всегда хорошо!");
}
} script>
В данном коде у нас есть три функции: добавление и удаление гостя и проверка количества гостей.
В функции добавления мы берем введенные данные guestsInput и добавляем их в лист listOfGests. Устанавливаем значение чекбокса в false (в нашем случае, это значит, что человек придет / если значение true, то есть галочка стоит - значит не придет), после чего очищаем поле ввода. Далее увеличиваем счетчик гостей и вызываем функцию проверки их количества.
В функции удаления мы берем список гостей listOfGests и проверяем значение чекбокса каждого гостя, определяя, кто придет, а кто нет. Удаляем тех, кто отмечен галочкой (не пойдет) и уменьшаем счетчик элементов.
Функция проверки количества гостей очень проста, поэтому подробнее мы ее разбирать не будем.
Давайте откроем пример в браузере и поработаем с ним:
Добавим несколько гостей:
С изменением количества гостей содержимое оповещений будет меняться.
Когда вы добавите больше 9 друзей, тогда увидите такое оповещение:
Поздравляем, вот Вы и создали свое первое одностраничное приложение с помощью AngularJS!
ТОП помилок S'ales-менеджерів
Автор: Андрій Афанасьєв
Введение
Приходилось ли Вам, работая в интернет-агенстве или веб-студии, сталкиваться с ситуациями, когда у Вас возникали разногласия с S’ales-менеджерами (менеджерами по продажам услуг компании)? Лично у меня они возникают чуть ли не ежедневно. Вроде бы и цели у нас общие – выстраивать мощный бизнес и зарабатывать хорошие деньги. Но технари и менеджеры по продажам , оказывается, настолько разные по своему мышлению, и идем мы к этим глобальным целям разными дорогами. В данной статье я хочу разобрать психотип технического специалиста и продажника. Исходя из этого мы сможем понять:
Почему возникают спорные ситуации между отделом продаж и отделами по производству;
Какие стандартные “косяки” допускают менеджеры по продажам, которые в дальнейшем существенно вредят производственникам;
Как попытаться избавиться от этих ошибок раз и навсегда.
Основные особенности психотипа технаря
Техническими специалистами в такой структуре, как веб-студия, являются SEO-специалисты, PPC-специалисты, программисты, маркетологи, аккаунт-менеджеры, менеджеры проектов, руководители отделов и другие позиции, которые в этом перечне я случайно мог пропустить. Основная цель технаря – максимально качественно закрывать вопросы разработки стратегии и реализации работ для достижения максимального результата, будь то контекстная реклама, поисковое продвижение или разработка сайтов.
Мышление и построение работы данных категорий сотрудников построено преимущественно на:
Систематичности;
Педантичности;
Четкой последовательности действий, которые формируются на составлении четких дедлайнов (сроков) по каждой задаче и процессу;
Тайм-менеджменте (детальном планировании всего рабочего времени);
Отсутствии какого-либо хаоса и утверждение всех нюансов с заказчиком.
По моему мнению, это идеальная схема построения рабочего процесса технического специалиста, который сможет четко и слаженно, как часовой механизм, решать свои задачи в рамках той компании, в которой работаю сейчас я. С большой вероятностью, у других компаний и фирм данный секрет успеха отличается от того, что приведен выше. Рассмотрим теперь особенность настроев S’ales-менеджеров.
Настрои сейлзов
Как бы гениально это не прозвучало, но основная задача продажника – много продавать. Продавец должен быть стрессоустойчивым, уметь подать продукты компании в такой упаковке, чтобы покупатель, не раздумывая, хотел стать клиентом компании. Исходя из этого, менеджеры по продажам пользуются следующими векторами в своей работе:
Нагенерировать как можно больше лидов (людей, которые проявили хотя бы минимальный интерес к продукту) путем обработки, например, входящих обращений или холодных звонков;
Постоянно контактировать с лидами до момента, пока клиент все-таки не подпишет договор и не заплатит деньги;
Назначить как можно больше встреч, где убедить клиента в целесообразности и необходимости услуг проще, чем по телефону;
Выполнить план продаж путем заключения как можно большего количества договоров.
Такие настроения оправданы, потому что зачастую мотивация S’ales-менеджера состоит из небольшой ставки + хорошего процента от суммы бюджетов подписанных договоров. Поэтому основной кусок пирога заложен именно в этой процентной части.
А теперь про типичные «косяки» продажников
Настоящий менеджер по продажам – это охотник за процентами. На этом я уже поставил акцент в предыдущем пункте. Когда я наблюдаю за своими коллегами-сейлзами, порой у меня возникает ощущение, что они готовы на все ради продажи. Извините, я без критики и осуждения. Просто такое рвение доставляет нам неприятности и проблемы следующего характера:
Продажа ради продажи. Иногда к нам на стол попадает такой проект, с которым ты просто не знаешь, что делать, либо который со старта обречен на провал. Проходит месяц-два, и клиент отказывается от услуги, потому что, к примеру, SEO на первых порах не тот тип рекламы, который нужен проекту.
Несогласованный или весьма заниженный бюджет на проект. Бывают такие ситуации, что ко мне подходят и говорят что-то типа: “Клиент очень «горячий». Можем подписать прямо сейчас, если ты дашь добро. У него бюджет 3500 грн., из которых на ссылки 1000 грн.”. И это при среднем чеке компании, например, в 6000 грн. и очень конкурентной тематике проекта типа котлов или окон. Увы, с таким бюджетом нет смысла заходить на рынок. Да и коммерческий интерес компании-исполнителя невелик.
Не доходит ключевая информация. Для лучшего понимания проблематики смоделирую ситуацию. Например, у нового клиента компании есть два сайта A и B одной тематики. Сайт A клиент хочет продвигать, а сайт B – старый, который он трогать не хочет. Сайт B имеет уже какую-то видимость и позиции, но является аффилиатом по отношению к A, поэтому отдел SEO предлагает клиенту склеить 301 редиректом непродвигаемый сайт с продвигаемым. Когда поступает такое предложение, клиент возмущенно говорит, что сайт B уже продвигался ранее другой компанией и попал под текстовый фильтр Panda, и основная идея появления нового сайта A и его дальнейшей раскрутки связана именно с этим. И немаловажно то, что заказчик утверждает, что вся эта информация была донесена до менеджера, который подписывал договор. Чья недоработка и в чем она заключается, я думаю, понятно…
Обещание золотых гор. Ради подписанного договора сейлз на эмоциях может пообещать клиенту четкие сроки и даже гарантии на вывод в ТОП. Это большая ошибка, которую потом придется разгребать аккаунт-менеджерам. Клиента нужно обязательно ориентировать на какие-то примерные сроки, но давать 100% гарантии на вывод в ТОП никак нельзя. Гарантировать можно только максимально внимательный и профессиональный подход и перечень работ, прописанных в договоре.
Включение в общий бюджет дополнительных доработок. Иногда те лиды, которые являются «горячими» или «теплыми» манипулируют до безумия заинтересованным в продаже менеджером. Это может заключаться в том, что заказчик обещает долгосрочное сотрудничество по SEO-оптимизации или продвижению, если в общий бюджет будут включены некоторые доработки по сайту. И очень часто заказчики почему-то считают, что все они весьма простые типа CTRL+C и CTRL+V и все готово. То ли от незнания специфики правок, то ли от желания докрутить клиента до продажи как можно быстрее, менеджеры часто обещают: ”Все просто. Все будет. Все сделаем!” И в 80% случаев эти доработки оказываются такого масштаба, что в рамках лояльности их не сделаешь и нужно оценивать отдельными сроками и бюджетами. На эти грабли менеджеры наступают регулярно и до тех пор, пока их не заставляют самостоятельно выруливать такие ситуации. Такое нужно мгновенно искоренять!
Это далеко не весь список казусов, которые происходят с менеджерам по продажам. Это золотая классика, которая, я уверен, повторяется у многих компаний и фирм данного сегмента бизнеса.
Как искоренить весь этот бардак?
Это намного проще, чем может показаться на первый взгляд. Для этого всего лишь нужно:
Ввести обязательную систему брифования со стандартным списком вопросов, которые еще на этапе переговоров помогут получить важную информацию для составления более-менее прозрачой картины о проекте будь-то SEO, контекст или веб;
Внедрить многоуровневое утверждение проектов через руководителей отдела продаж, отдела по производстенной части и аккаунтинга. Пока каждый руководитель детально не изучит условия договора и особенности заказа, ничего подписано быть не должно!
Использовать систему передачи проекта в письменном виде руководителям отделов со стоимостями по проектам. (Как, сколько, за что клиент заплатил и что должен в итоге получить);
Проведение периодических ликбезов и занятий, на которых менеджеры по продажам могут задавать вопросы техническим специалистам, тем самым повышать свой уровень до уверенной компетенции в продукции.
Ну, и как резюме…
Подытожить данный материал, над которым я работал не один вечер, хочется следующим обращением:
Уважаемые менеджеры по продажам.
Мы Вас очень ценим и уважаем. Вы - локомотив нашего бизнеса и от Вас зависит многое. Но, пожалуйста, согласовывайте с нами каждый нюанс и мелочи и прислушивайтесь к производственникам Вашей компании. Давайте жить дружно ;)
Співбесіда з DevOps. 300+ питань для Junior, Middle, Senior
Автор: Влад Сверчков
Junior
1.1 Общие вопросы и Linux.
1.2 Networks, Clouds.
1.3 Automation, Information Security.
1.4 Виртуализация, CI/CD, Development.
1.5 Monitoring/Logging.
1.6 Практические задания.
Middle
2.1 Linux.
2.2 Networks.
2.3 Container orchestration.
2.4 Виртуализация и контейнеризация.
2.5 CI/CD, Clouds and Automation.
2.6 Monitoring/Logging.
2.7 Information Security.
2.8 Development, Databases.
2.9 Практические задания.
Senior
3.1 Linux.
3.2 Networking, Разное.
3.3 Container orchestration, Clouds and Automation.
3.4 CI/CD, Information Security.
3.5 Observability, Databases.
3.6 Практические задания.
Дорогие друзья! Предлагаем вашему вниманию перевод статьи, опубликованной на DOU.ua 7 декабря 2021 года. Оригинальная версия на украинском языке доступна по ссылке.
Можно спорить о популярности DevOps, а можно просто готовиться к собеседованию и получить желанные 9K :) Чтобы помочь вам сориентироваться в вопросах, которые задают на интервью, мы поговорили с теми, кто их проводит, и составили список возможных вопросов.
Junior
Общие
1. Что такое DevOps?
2. Вы набираете google.com в браузере. Расскажите как можно подробнее, что происходит в это время?
3. Как работает HTTPS?
4. Объясните концепцию Infrastructure as Code, зачем это нужно и какие проблемы решает?
Linux
5. Опишите общую архитектуру операционной системы.
6. Опишите основное предназначение операционной системы.
7. Зачем нужны файловые системы? Какие существуют?
8. В чем разница между виртуализацией и контейнеризацией?
9. В чем преимущества контейнеров?
10. Какова файловая структура в Linux (UNIX) системах, расположенных в /etc, /dev, /proc, /sys, /lib, /var (несколько директорий на выбор)?
11. Что такое Load Average?
12. В чем разница между soft и hard symlink?
13. Как работают file permissions, зачем директории права исполнения (+x)?
14. Что такое zombie process?
15. С помощью чего можно собрать информацию о текущем состоянии процессора, памяти, диска, сети?
16. Что такое swappiness?
17. Как посмотреть свободное место на диске?
18. Что такое inode?
19. Расскажите поэтапно процесс загрузки Linux с момента включения питания компьютера.
20. Что произойдет при выполнении команд:
1. cat file1 > file2
2. cat file1 >> file2
21. В чем разница между Ctrl+C и Ctrl+Z?
22. Как перенаправить одновременно stderr и stdin?
23. Как убить процесс? Какие есть типы сигналов?
24. Что делает команда grep?
25. Что такое скрипт bash?
26. Какие типы переменных используются в bash?
27. Что выведут команды:
1. echo ${hostname};
2. echo $(hostname);
Networks
28. Что такое модель OSI, TCP/IP?
29. Для чего нужны network masks?
30. Структура IP-пакета. Из чего состоит? Что такое фрагментация и почему она происходит?
31. Что такое коллизия? Почему возникает?
32. Что такое прокси?
33. Что такое firewalls и зачем они нужны?
34. Что такое NAT и для чего он нужен?
35. Какие типы IP-адресов вы знаете?
36. По какому порту и протоколу работают Ping и Traceroute?
Clouds
37. В чем разница между IaaS, PaaS и SaaS?
38. Что такое VPC и из каких компонентов должно состоять?
39. Что такое cloud-init? init/systemd/upstart configs?
Automation
40. Что такое IaaC и зачем он нужен?
41. Что такое Terraform?
42. Какие инструменты автоматизации вы знаете?
Information Security
43. В чем разница между аутентификацией и авторизацией?
44. Сертификаты. Как работает HTTPS? Что такое certificate ciphers?
45. Как безопасно передать данные своему коллеге?
46. Что такое MFA, TOTP?
Виртуализация
47. В чем разница между виртуализацией и контейнеризацией? В чем плюсы и минусы?
48. Как при запуске Docker-контейнера «повесить» его из 80-го порта в контейнере на 8081 на хост?
49. Как передать в виртуальную машину USB device?
50. Docker-контейнер потребляет многие SWAP. Что делать?
CI/CD
51. Что такое Continuous Integration и Continuous Deployment? В чем разница между Continuous Deployment и Continuous Delivery?
52. Опишите основные этапы CI/CD.
53. Опишите пример процесса CI (и/или CD), который начинается с момента, когда разработчик запушил изменения/PR в Git?
54. Расскажите о разновидностях тестов, которые мы можем использовать в CI пайплайне.
55. Какие инструменты CI вы использовали? Есть ли опыт работы с Jenkinsfile?
56. Какие виды тестов вы знаете и зачем они нужны?
Development
57. Git. Как решить merge conflict? Что такое rebase, cherry-pick?
58. В чем разница между git merge и git rebase?
59. Какие UI использовали?
60. Какая разница между GitLab/GitHub/Bitbucket?
61. Какая разница между Git pull/Git fetch?
62. Что такое Git-Flow?
63. Версионирование. Какая разница между SemVer и CalVer?
64. Тестирование. Какие существуют виды? Как писать тесты, TDD?
65. В чем разница между компилируемыми и интерпретационными языками программирования?
Monitoring/Logging
66. Какие метрики нужно собирать? Разница между infrastructure и application monitoring.
67. Какая разница между pull и push model в системах мониторинга?
68. Какая разница между Black box и White box monitoring?
69. Расскажите о подходах к сбору application логов.
Практические задания
71. Напишите простую программу на ваш выбор. Программа должна получать сообщения из сервиса очередей и печатать его в stdout. Сервис очередей — по вашему усмотрению.
72. Разберите структуру сервиса (на примере Docker-Compose).
73. Практическая сессия работы с Git (Git command line: fetch, push, pull, rebase, checkout, submodules).
Middle
Linux
1. Опишите архитектуру ядра Linux.
2. Что такое ядро и каково его предназначение?
3. Опишите общие части файловой системы Unix/Linux, архитектуру файловой системы.
4. В чем разница между RedHat и Debian?
5. В чем разница между /proc и /sys?
6. Ситуация: указывает, что на диске занято 50% места, а сделать файл даже под root юзером не можем. В чем проблема?
7. Мы удалили файл, открывший приложение. Как нам его восстановить?
8. Как найти PID процесса, его стартовые параметры?
9. Как проверить, открыт ли порт на удаленном хосте, локальном хосте?
10. Как искать файл по его содержимому?
11. Что такое SSH, как организовать доступ на сервер без пароля или с определенных хостов? Как ограничить доступные для выполнения команды?
12. Как проверить потреблённые ресурсы во время сеанса SSH?
13. Что означает разрешение на файл 755?
14. Что такое SELinux и зачем он нужен?
15. Как определить PCI-устройство в системе, например, RAID controller?
16. Как переименовать устройство, например, сетевую карту или диск?
17. Что такое LVM? Какие знаете примеры использования?
18. Что такое root reserved space?
19. Что такое exit code и как его узнать?
20. Почему вывод df -h указывает, что на диске занято мало места, но система не дает записать файл с сообщением “no space left on device”?
21. В чем разница между command1 & command2 и command1 && command2, а также command1 && command2 || command3?
22. Из сети резко вырос исходящий трафик на 25-й порт. Как, имея доступ на гейтвей, обнаружить вредителя из внутренней сети?
23. Как затюнить параметры Linux Kernel?
24. Что такое ulimits?
25. В чем разница между символическими и hard links?
26. Что такое фрагментация ext3 и ext4?
27. Зачем файловые системы ext* резервируют 5% места?
28. Как увеличить размер файловой системы?
29. Можем ли мы уменьшить размер файловой системы?
30. Что такое chroot и для чего он нужен?
31. У нас есть Linux box с 2 Гб оперативной памяти и Java-приложение, которое пытается выделить 4 Гб во время запуска. Удастся ли это?
32. Есть приложение, которое читает файл, который пользователь пытается удалить. Что случится? Можно ли удалить этот файл? Можно ли восстановить этот файл?
33. Какие механизмы создания процессов в Linux вы знаете?
34. Сравните systemd и init system.
35. У вас есть папка с большим количеством файлов, и вы хотите удалить все файлы с именами, начинающимися на A (прописная буква). Но команда rm –f A* выдает Argument list too long. Как удалить эти файлы?
36. Вы начинаете удалять файлы первым методом из предыдущего вопроса, но каждый rm запрашивает подтверждение. Это очень долго. Как можно ускорить эту операцию?
Networks
37. Расскажите о модели OSI. Опишите функции и назначение каждого уровня.
38. Какие сетевые топологии вы знаете? Опишите разницу между ними.
39. Зачем нужен IP-адрес, если MAC-адрес уникален? Разве мы не можем общаться только по MAC-адресу?
40. В чем разница между концентратором и коммутатором L2 в сетях Ethernet?
41. Что такое VLAN и для чего существует разделение на виртуальные локальные сети?
42. Какой номер порта используется для PING-коммуникации?
43. Что такое сеанс связи? Какой алгоритм использует TCP для доставки?
44. В чем основное отличие между TCP и UDP?
45. Зачем нам маршрутизатор по умолчанию?
46. Как хост решает DNS по умолчанию?
47. Компьютер начал получать IP-адрес из другой сети (есть подозрение, что в сети работает другой DHCP-сервер): как его найти и отключить? Какие методы защиты от такой проблемы?
48. Мы будем мигрировать сайт на новый IP-адрес. Как сделать, чтобы пользователи этого практически не заметили?
49. Что такое socket?
50. Как узнать, какие удаленные хосты подключаются к хосту через порт 8888? (с помощью команд и не используя /proc или /sys).
51. У нас есть несколько сетевых карт. Как увеличить пропускную способность сервера?
52. Как проверить открытые порты на удаленном сервере без команд Netcat или Nmap Linux?
Container orchestration
53. В чем преимущества Kubernetes как платформы?
54. Что такое control plane и из каких компонентов состоит?
55. Какие CNI вы использовали и чем они отличаются?
56. Чем отличается managed Kubernetes от self-deployed?
57. Как можно контролировать размещение подов в кластере? (taints/tolerations, affinities, topologies etc.)
58. Скейлинг кластера. Cluster autoscaler vs HPA vs VPA? Как сделать zero-downtime node decommission/cluster upgrade? PDB? Lifecycle hooks?
59. Какие способы для внешнего доступа к кластеру? ingress, node port, port-forward и т. д.
60. С каким PID запускается процесс в контейнере?
61. Что лучше использовать для изоляции окружения – Vagrant или Docker?
62. Какой инструмент оркестрирования контейнеров использовали? (Swarm, Kubernetes, Openshift, Rancher и т. д.)
63. Что происходит в Kubernetes после запуска kubectl (API, ReplicaSet Controller, storage back-end, scheduler, kubelet, worker node, pod)?
64. Какая разница между pod и контейнером в K8s?
65. Как мы можем сделать любой микросервис, работающий на K8s, доступным из внешней среды?
Виртуализация и контейнеризация
66. Какие типы виртуализации вы знаете?
67. Как работает Docker на macOS/Windows?
68. Что такое Docker-image и Docker-контейнер? Как они между собой связаны?
69. Каковы основные отличия между контейнерами докеров и виртуальными машинами?
70. Что такое image layer? Какое максимальное количество layers возможно? Почему нужно пытаться иметь малое количество layers? Какое оптимальное количество?
71. Как в виртуальной машине изменить размер диска после создания? Что нужно сделать с гостевой ОС?
72. Как в Docker реализовано ограничение ресурсов?
73. Существует виртуальная машина, к которой потерян доступ. Как, имея доступ к диску, восстановить root пароль/SSH-ключ?
74. Оптимизировать Dockerfile, объяснить, что и почему так:
FROM golang
RUN apt install -y pkg1 pkg2 pkgN # Dependencies for app
COPY. .
RUN go build -o app main.go
CMD ./app
75. Что такое IPVS и какой у него функционал?
76. Какова структура API в Kubernetes?
77. Что такое operators и зачем они нужны?
CI/CD
78. Какие стадии должны быть в любом пайплайне (lint, test, build, deploy etc.)?
79. Как и где хранить build artifacts?
80. Что такое артефакт?
81. Есть два бренча: dev и stage. Мы забросили Dockerfile в dev, а затем сбилдили в dev и stage. Это будет одним артефактом или разными?
82. Что вы использовали для автоматизации настройки Jenkins и GitLab CI?
83. Сравните CI инструментов: Jenkins, GitLab CI, AWS Code Pipeline, GCP cloudbuild, GitHub actions, Circle CI.
84. Deployment strategies. Какие существуют и чем отличаются (recreate, blue-green, canary etc.)?
85. Как реализовать СI/CD для программы, которая зависит от нескольких других программ?
86. GitOps. В чем его преимущества и недостатки?
Clouds and Automation
87. Какова роль и преимущества облачных сервисов для DevOps?
88. Что такое immutable infrastructure? Как достичь? В чем преимущества и недостатки? Packer, AMI и т. д.
89. Структура Terraform. Как организовать multi-environment project? Terraform workspaces?
90. Лучшие практики по использованию многих Terraform states.
91. Как организовать доступ команде разработчиков к AWS/GCP/Azure? Role-based access, assume role, SSO.
92. Что такое Terraform provider, module?
93. Как версионировать Terraform modules?
94. Когда нужно использовать local-exec и remote-exec?
95. Что такое golden image и как его создать?
Monitoring/Logging
96. Как мониторинг помогает поддерживать всю архитектуру системы?
97. Какие инструменты мониторинга вы использовали?
98. Что такое медиана и процентиль?
99. Что такое SLI, SLO, SLA? Зачем это нужно?
100. Архитектура системы для сбора логов, ELK, EFK etc. Как сохранить логи при отказе хранилища? Нужно ли использовать для этого брокер сообщений? Нужно ли делать throttling/rate limits?
101. Prometheus long-term storage. Какие варианты?
102. Как работает Prometheus?
103. В чем принципиальное отличие между Grafana и Kibana?
104. В чем главное отличие между Ansible and Terraform?
105. Что такое SAAS monitoring и какие виды знаете?
106. Если вы используете Datadog/NewRelic, то как нам отслеживать падение инструментов мониторинга?
107. Что такое distributed tracing и error tracking systems? Как вы думаете, когда следует их использовать?
Information Security
108. В чем разница между RBAC и ABAC?
109. В чем заключается XSS атака? SQL injection? Что такое CSP?
110. Какие базовые меры можно предпринять для защиты SSH-соединения?
111. Root-пароль неизвестен или потерян. Какова процедура восстановления?
112. Как управлять правами на файловой системе в Linux?
113. Что такое Firewall?
114. Чем отличается stateless от stateful фаерволов?
115. Сколько таблиц в iptables?
116. Можно ли настроить трансляцию NAT с помощью iptables? Какую таблицу следует использовать?
117. Какую таблицу используют для смены заголовков пакетов?
118. Если вам ломают Linux-сервер, то как более эффективно блокировать трафик с IP-адресов?
119. Принцип работы GCP Firewall: можем ли мы профильтровать трафик на Load Balancer?
120. Что такое SELinux?
121. Можно ли полностью отключить SELinux на лету?
122. С какими secrets management systems вы работали?
123. У нас есть сервер NAT, и мы хотим обеспечить доступ по IP к серверу снаружи. Как нам это реализовать?
123. Чтобы попасть на сервер клиента, нужно залогиниться на 4+ jump хоста. Как автоматизировать? Где мы будем хранить наш SSH-ключ?
Development
125. Что такое cookies? Зачем нужны? JWT?
126. Что такое feature toggles и зачем они?
127. Что такое TDD (Test Driven Development) и BDD (Behaviour Driven Development)?
Databases
128. Что такое индекс и что такое ключ?
129. Каковы преимущества и недостатки индексов?
130. Представьте, что вы разрабатываете систему биллинга, которая должна обрабатывать тысячи счетов. Какую стратегию обновления данных вы бы выбрали?
131. Какие методы чаще всего используют для масштабирования реляционных баз данных?
132. Опишите механизм транзакций БД.
133. Как мы можем удалить таблицу или базу данных?
134. Как найти медленные запросы в MySQL/PostgreSQL?
135. Какие SQL-операторы манипулирования данными вы знаете?
136. Можно ли вывести список баз данных/таблиц через CLI? Как мы можем переключаться между базами данных MySQL/PostgreSQL?
137. Какие storage engines в MySQL вы знаете? Какие отличия?
138. Как реализована репликация MySQL master-master? Сколько серверов MySQL может быть задействовано в таком взаимодействии?
139. Как работает репликация MySQL/PostgreSQL? Какие параметры должны быть настроены для репликации?
140. Сравните SQL и NoSQL.
141. Sharding vs replication?
142. Какие есть виды индексов? Когда и зачем использовать?
143. Требования к схеме БД. Character sets, collations, default, not null и т. д.
144. Мы мигрируем MySQL/PostgreSQL из on-prem в облако. Как нам это сделать с минимальным даунтаймом?
145. Зачем и как тестировать перформанс баз данных?
Практические задания
146. Напишите Terraform module для инфраструктуры тестового сервиса в AWS.
147. Напишите hello-world программу на ваш выбор и сформируйте для нее helm chart/kustomize.
148. Как организовать деплой без downtime?
149. Опишите способы troubleshooting для Docker-контейнера.
150. Разобрать и объяснить структуру CI/CD pipeline (на примере gitlab.yml).
151. Продемонстрируйте навыки работы с GitOps, опишите деплоймент простенькой программы.
152. Как организовать деплой веб-приложения, запущенный на нескольких серверах без (или с минимальным) downtime?
153. Как с помощью Ansible узнать default gateway для пула серверов, и, если он отличается от желаемого, записать строчку «hostname: gateway» в файл на локальной машине?
Senior
Linux
1. Что может создавать высокую нагрузку на CPU (процессы приложений потребляют очень мало ресурсов CPU)?
2. У нас нет команд ifconfig, ip, и поставить мы их не можем. Как нам узнать ip address, mask, network, routes?
3. Что такое suid, sgid и sticky?
4. Что тюнилось с системой для нагрузки трафика 1GB, 10G, 40G+?
5. Что тюнилось с системой для высокой нагрузки на диск?
6. Что такое Linux namespaces?
7. Что такое Ceph, как работает?
8. Что нужно тюнить для Ceph?
9. Что произойдет, если /dev/sda1 перенесем в /root?
10. Мы удалили /dev/sda1. Как нам его восстановить? Что такое pseudo-devices?
11. Нам хакнули сервер, и в директории /var/www создали два миллиона файлов небольшого размера. Если использовать команду cd /var/www и затем rm -rf*, то у нас зависнет терминал. Как удалить файлы?
12. На каком уровне работает iptables?
13. Что такое eBPF и зачем нужен?
14. У вас есть файл, содержащий IP-адреса серверов (по одному в строке). Есть SSH доступ к этим машинам, и вам нужно выполнить задание (например, установить список пакетов на все узлы). Объясните, как можно это сделать.
Networking
15. В чем отличия между IPv4 и IPv6? Зачем мы мигрируем на IPv6?
16. Сосуществование IPv4 и IPv6: что это значит?
17. Действительно ли работают межсетевые экраны с поддержкой IPv6?
18. Как работает DHCPv6? Чем она отличается от DHCPv4?
19. Как фрагментируются пакеты IPv6 и чем это отличается от IPv4?
20. Нужно ли с IPv6 больше использовать NAT?
21. Что такое DPDK?
22. Что такое SR-IOV? В чем разница между DPDK и SR-IOV?
23. Что такое NetFlow и зачем нужен?
24. Что такое OpenFlow?
25.Что такое SDN и какие контроллеры вы знаете? Сравните контроллеры.
Разное
26. Что такое SDLC?
27. Расскажите о последнем опыте реализации архитектуры для сервиса.
28. Какой самый тяжелый скрипт писали?
29. Что такое configuration drift? Почему это происходит и как это усложняет жизнь инженерам\SRE\Ops?
30. Расскажите об архитектуре, за которую вы отвечаете, и укажите, как она масштабирована и отказоустойчива.
31. Назовите три важных KPI для DevOps-специалиста.
32. Как работает Kafka (clusters(brokers, controllers), topics, partitions)?
33. GitOps: Rancher Fleet vs Flux vs Argo?
34. Как использовать GitOps для обновления документации DevOps-приложений?
35. Расскажите об особенностях проектирования Kubernetes on-premise.
36. Как организовать On-call процесс для команды DevOps?
37. Опишите главные шаги загрузки операционной системы Linux.
Container orchestration
38. Service mesh. Что это такое и зачем нужно?
39. Cluster federation. Что это такое и зачем нужно?
40. Pod fine-grained access. Как реализовать? IRSA vs kube2iam vs kiam?
41. Как реализованы услуги в кубернетах?
42. Как дебажить трафик контейнера?
43. Что такое unikernel и зачем он нужен?
44. Почему коммьюнити переезжает из Docker containerd?
Clouds and Automation
45. Какие преимущества и недостатки cloud-провайдеров?
46. Cost оптимизация. Какие инструменты? Spot/preemptible instances, reservations?
47. Как организовать multi-account, multi-region cloud setup?
48. В чем разница между частными и публичными сетями в AWS?
49. AWS Lambda: имели ли опыт работы?
50. Когда следует переходить на AWS Lambda? Когда не стоит? Аналогичные решения в GCP или Kubernetes?
51. Когда лучше использовать CloudFormation, а когда Terraform?
CI/CD
52. Что такое state в контексте использования Terraform?
53. Какие существуют branching strategy? На что опираться при выборе?
54. Как реализовать feature/dynamic environments?
55. Как сделать эмуляцию ресурсов cloud-провайдера для локального тестирования и ускорения разработки?
56. Что такое MultiCloud?
57. Что такое Cloud-Agnostic и когда он потребуется?
58. Что такое Hybrid-Cloud и с какими решениями вы работали?
Information Security
59. Как должны храниться пароли в базах данных (Salt&Pepper, Rainbow Tables, Adaptive Hashing)?
60. Как передавать секреты в application (Secrets management)?
61. Сравните CI/CD SAST и DAST?
62. Какие вы знаете Kubernetes security practices? RBAC? OPA? Какие недостатки RBAC и какие кейсы знаете?
63. Расскажите о защите от DDOS атак, WAF.
64. Что такое Rootless containers и для чего он нужен?
65. Что такое AppArmor и Seccomp и зачем они нужны?
66. Приходилось ли работать с Falco? Если да, то что реализовывали?
67. HashiCorp Vault и как правильно передать нам секреты в контейнере и CI pipeline?
68. Что такое Admission Controllers и какие вы использовали?
69. Как хранятся секреты etcd? Как просмотреть ресурсы в etcd?
70. Чем проверяете на уязвимости ваш Kubernetes cluster?
71. Что такое Secure SDLC?
72. Что вы знаете о Cloud Infrastructure Attack via a Pull Request и как этого избежать?
Observability
73. Что такое observability и чем отличается от обычного мониторинга? Какие особенности необходимо учитывать в микросервисной архитектуре (tracing)?
74. Что такое SLI, SLO, SLA и зачем они нужны? Для чего используют error budget?
Databases
75. Что такое теорема CAP? Зачем это нужно?
76. Как работать с миграциями? Что делать в случае rollback? Как проверить, что миграция backward-compatible?
77. Опишите, как бы вы оптимизировали работу базы данных? (БД по выбору кандидата) Slow queries, buffers, thread pools?
78. Зачем нужно тестировать перформанс базы данных и какими инструментами?
Практические задания
79. Представьте, что вы CTO Booking или Airbnb. Какие бы вы принимали решения касательно:
языков программирования.
Infrastructure as a Code.
архитектуры инфраструктуры.
настройки CI/CD.
80. У вас есть файл, содержащий патчи в директории. Например:
/var/tmp/temp/file1.c
/var/tmp/file.ext
/var/tmp/temp/
etc... один путь в строке. Если путь заканчивается на '/' — это путь в каталог. Вам нужно восстановить это дерево каталогов с пустыми файлами в другой файловой системе. Напишите bash-скрипт.
81. Представьте, что вам нужно убедить Spotify, использующего AWS, перейти на GCP. Как вы будете мотивировать Spotify мигрировать на GCP?
82. Есть сервисная компания, предоставляющая сервис трекинга перевозок. Есть клиенты, которые не желают, чтобы их данные процессировались в AWS. Как нам реализовать multi-cloud solution?
Редакция DOU выражает благодарность за помощь в подготовке статьи: Владу Волошину, Павлу Петриченко, Виталию Гарбулинскому (BrightLocal), Евгению Думе, Сергею Яремчуку, Вадиму Шкилю, Александру Билюку, Александру Нежинскому, Владиславу Граму, Станиславу Коленкину, Олегу Миколайченку, Антону Гаврилову.
Хто такий Full-stack розробник
Автор: Влад Сверчков
Суперечки навколо Full-stack
Різновиди Full-stack розробників. Стек мов та технологій для кожного
Плюси професії Full-stack Developer
Мінуси професії Full-stack Developer
Як стати Full-stack розробником?
Зарплати Full-stack розробників
Підсумки
Оновлено 9 червня 2023 року
Привіт, друзі!
Full-stack розробник (вимовляється "фул стек") – це якийсь майстер на всі руки у світі веб-розробки. Йому під силу реалізувати як клієнтську, так і серверну сторону додатку, якими, зазвичай, займаються FrontEnd і BackEnd розробники окремо один від одного. Таким чином, Full-stack спеціаліст здатний одноосібно вести проєкт від початку до кінця.
Ще в далеких нульових і раніше не існувало такого розподілу обов'язків між розробниками. Відносна простота ПЗ, що розроблялося, так само як і технології того часу дозволяли тримати процеси, які зараз виконують різні люди, в одних руках. Наприклад, у ті часи IT-фахівець, який називається веб-майстром, і зовнішній вигляд сайту створював, і серверну частину реалізовував, і розміщував сайт на хостингу. Тобто, Full-stack розробники існували і раніше, просто ніхто їх так не називав.
Однак IT-сектор не стояв на місці. Вимоги до програмних продуктів зростали, з'являлися нові мови та технології, змінювалися підходи до розробки. Дерево IT почало ставати все більш гіллястим, породжуючи нові спеціальності. Разом із цим професія універсального бійця розбилася на два окремі напрямки, а потім знову відродилася з гордою назвою "Full-stack Developer".
Суперечки навколо Full-stack
Не все так гладко, як здається на перший погляд. Багато досвідчених програмістів та IT-фахівців вищої ланки не визнають цю посаду за визначенням. "Чому?" — спитаєте ви. Адже раніше були ті самі веб-спеціалісти, які успішно поєднували обов'язки сучасних напрямків — фронту та беку. Чому сьогодні поняття Full-stack викликає суперечки?
Поширеною є думка, що Full-stack розробників не існує, а ті, хто такими називаються, насправді не відповідають вимогам цієї спеціальності.
Наприклад, Сергій Немчинський — програміст з 20-річним стажем, керівник та власник навчально-виробничої компанії FoxmindEd — в опублікованому відео на YouTube відгукується про Web Full-stack розробників наступним чином (посилання):
“В принципі, в ідеалі, Full-stack розробник – це класно та чудово. Проблема в тому, що... Таких немає. Фактично все, що ми маємо на ринку з тих людей, які називають себе Full-stack девелоперами – це приблизно 50% BackEnd девелоперів, які трошки вивчили FrontEnd і вже можуть Angular або React скомпілювати і, відповідно, зібрати-підключити, плюс трошки розуміють у верстанні – навіть не на рівні Junior верстальника. Вони у більшості випадків зробити добре, красиво не можуть ніяк. Максимум, що можуть – зробити так, щоб кнопка натискалася.
Або ж Full-stack девелопери – це решта 50% FrontEnd розробників, які трошки вивчили BackEnd; в більшості випадків – якийсь Node.js. Можливо, PHP. Такий розробник мінімально вміє щось підрихтувати, але, знову-таки, говорити про те, що він сяде і напише вам нормальний Full-stack додаток – ні, ні і ще раз ні.
(…)
Чесно скажу, мені ідея з об'єднанням у Full-stack девелоперів здається, з одного боку, не дуже вдалою, тому що фактично ми отримуємо "ні риба, ні м'ясо". З іншого боку, ринок вимагає – отже, треба. Тому затребуваність у Full-stack девелоперів, за великим рахунком, трохи більша, ніж у чистих BackEnd або FrontEnd розробників. Однак ринок вже усвідомив, що вони (Full-stack розробники) у своїй більшості "ні риба, ні м'ясо", і тому термін "Full-stack" починає пропадати. Тепер просто вважається, що це BackEnd розробник з невеликим знанням фронту і, навпаки, FrontEnd розробник з невеликим знанням однієї з BackEnd мов. Мені здається, що так набагато правильніше”.
Інші розробники схиляються більше до того, що Full-stack розробка – це ні що інше, як хитрощі бізнесу. Роботодавець не бажає переплачувати за двох різних фахівців, віддаючи перевагу більш дешевому аналогу, котрий вміє все те саме.
По суті, вся суперечка щодо Full-stack розробника зав'язана на скептицизмі. Прихильники міфологічності цієї професії не вірять у існування розробника, здатного добре реалізувати як FrontEnd, так і BackEnd частини, оскільки за обома ховається безліч технологій і мов, а вивчити все і працювати не гірше за фронтендерів і бекендників — практично неможливо.
Ті ж, хто займаються Full-stack девелопментом, парирують, вказуючи на велику кількість часу, проведеного за розробкою, в ході чого так чи інакше доводиться заглядати по інший бік барикад і розбиратися в усіх процесах, що супроводжують розробку всього проєкту від і до. Ну а далі справа техніки — вивчаєш необхідні інструменти, практикуєшся і можеш самостійно працювати над цілим проєктом. Звичайно, пізнання у всіх використовуваних мовах і технологіях у Full-stack спеціаліста будуть не такі глибокі, як у вузькоспеціалізованих побратимів по цеху, але зробити повноцінний робочий проєкт з нуля, реалізувавши як BackEnd, так і FrontEnd, йому буде під силу.
Різновиди Full-stack розробників
Варіацій Full-stack розробників насправді безліч: PHP Full-stack Developer, Node.js Full-stack Developer, Java Full-stack Developer і так далі. Назва, яка стоїть на початку спеціальності, говорить про те, яка мова/платформа береться за основу під час реалізації BackEnd частини. Стек технологій FrontEnd практично завжди однаковий і відрізняється лише використовуваними JavaScript-фреймворками / бібліотеками: Angular, React або Vue.js. А ось бекенд надає набагато більше можливостей для реалізації своїх амбіцій.
Ще раз проговоримо, що Full-stack Developer – це розробник, який бере безпосередню участь у всіх етапах розробки веб-додатків: від створення клієнтської частини (візуальна частина + логіка користувача) до реалізації серверної (бази даних, серверна архітектура, програмна логіка). Який стек технологій та мов знаходиться у розпорядженні цього фахівця? Якщо говорити про FrontEnd складову (клієнтська сторона), то вона у всіх приблизно однакова:
мова верстання HTML та мова стилів CSS;
мови програмування JavaScript та TypeScript;
препроцесори SASS та LESS;
фреймворк Angular/Vue.js або бібліотека React;
технології DOM, AJAX, REST API, знання про інтернет та веб-технології в цілому тощо;
навички адаптивного та кросбраузерного верстання.
А що потрібно знати full stack розробнику із серверного набору? Тепер розберемося з відгалуженнями в бекенді, які вказують на популярні мови та технології, що використовуються під час реалізації серверної сторони веб-додатків, котрі розробляються.
Node.js Full-stack Developer
BackEnd складова (серверна сторона) може мати різну начинку, на відміну від FrontEnd. Якщо говорити про Node.js Full-stack розробника, то в якості основної мови виступає JavaScript, а сам стек наступний:
платформа Node.js;
фреймворки Express.js, Nest.js;
пакетний менеджер npm;
Web Sockets;
розуміння REST API;
інші спеціалізовані технології.
Java Full-stack Developer
Головний акцент робиться на мову програмування Java та пов'язані з нею технології. BackEnd-стек у такого розробника має бути наступним:
мова Java + Java Core;
веб-сервер Apache;
інструменти для комфортної взаємодії з БД – JDBC, Hibernate;
веб-сервіси;
фреймворк Spring та його популярні модулі (Spring MVC, Spring Boot, Spring REST, Spring Web тощо);
ASP.NET Full-stack Developer
.NET розробники мають широкий інструментарій для самореалізації у вебі. Як основну мову програмування вони використовують C#. Скарбничка знань BackEnd частини у ASP.NET Full-stack Developer-а повинна містити:
мову C#;
знання інфраструктури .NET.
платформу ASP.NET MVC/ASP.NET Core (Web API);
Entity Framework (Core);
хмарний сервіс Azure;
мову T-SQL;
розуміння RESTful API.
PHP Full-stack Developer
PHP – класична мова веб-розробки. Типовий BackEnd-стек даного розробника відрізняється від інших своєю компактністю. РНР у вебі вже досить давно, а тому йому багато не потрібно; достатньо лише:
власне, сама мова PHP;
фреймворк Yii2/Symfony/Laravel.
Python Full-stack Developer
Універсальність Python не знає меж! Не стала винятком сфера веб-розробки. BackEnd-стек Python Full-stack спеціаліста наступний:
мова Python;
фреймворк Django/Flask;
REST API;
Web Sockets;
навички роботи з ОС Linux та веб-сервером Nginx/Apache (можливо);
досвід роботи із хмарними сервісами.
Також окрім спеціалізованих технологій, усім Full-stack розробникам необхідно:
знати систему керування версіями Git + сервіс для хостингу IT-проєктів GitHub;
знати реляційні (SQL) та нереляційні (NoSQL) бази даних, вміти їх проєктувати;
розумітися на протоколах HTTP, HTTPS та роботі FrontEnd + BackEnd загалом;
вміти оперувати мовою запитів SQL та однією із СУБД – MySQL / PostgreSQL / SQLlite, або однією з NoSQL СУБД (MongoDB, Redis, Cassandra, наприклад);
вміти проводити тестування додатків;
здійснювати Code Review;
використовувати Docker;
володіти англійською мовою на рівні Intermediate та вище;
знати популярні патерни програмування та вміти їх реалізовувати;
мати гарне знання алгоритмів та структур даних.
Також від Full-stack спеціаліста можуть вимагати навички мобільної розробки, якщо роботодавець має намір портувати веб-додаток на відповідні платформи.
Як бачите, список необхідних мов і технологій для створення гарної серверної складової веб-додатків є досить значним. У наступному розділі ми розберемося, які переваги та недоліки чатують на тих, хто таки має намір пов'язати свою професійну діяльність з Full-stack розробкою.
Плюси професії Full-stack Developer
Можливість самостійно вести цілий проєкт
Очевидна перевага розробника даної спрямованості полягає в об'єднанні двох течій – FrontEnd та BackEnd – в одному фахівці. Крім того, що такий професіонал здатний реалізувати обидві частини веб-додатку, він може безпроблемно налаштувати їхній взаємозв'язок, що є частим каменем спотикання між фронтендниками та бекендниками. Тим самим усуваються непорозуміння і протиріччя, які неминуче виникли б між декількома розробниками, які працюють над одним і тим самим продуктом.
В'ячеслав Лобода, Senior Full-stack PHP Developer, про свою професію відгукується наступним чином:
“Часто при вирішенні завдань веб-розробки виникає необхідність вносити редагування одночасно і до FrontEnd, і до BackEnd. Для цього можна найняти двох різних спеціалістів чи одного Full-stack розробника. Останній варіант дозволяє заощадити час на комунікацію”
Даний відгук і всі наступні взяті зі статті на dou.ua "Кар'єра в IT: посада Full-stack розробник".
Висока швидкість розробки, можливість приймати власні рішення, мінімальні витрати часу на зайву комунікацію
Full-stack розробник – це вже фахівець досить високого рівня, який здатний приймати певні самостійні рішення, не витрачаючи час на зайві обговорення та узгодження з іншими розробниками, адже проєкт цілком перебуває під його крилом.
“Подобається, що можу створювати веб-додатки одноосібно, менше затримок під час роботи. Наприклад, коли працюєш як FrontEnd і потрібно, щоб BackEnd віддавав нові дані, ти просиш колегу внести зміни, чекаєш. Full-stack розробнику чекати ні на кого не потрібно. Взяв і зробив як слід” – Геннадій Догаєв, Web Full-stack Developer
Легкість пошуку роботи на фрілансі
На біржах фрілансу замовники найчастіше шукають такого веб-спеціаліста, який зробить всю роботу самостійно без залучення додаткових розробників. Хто, як не Full-stack девелопер найкраще підійде на цю роль, маючи таку перевагу перед вузькоспеціалізованими побратимами? Отже, обравши цей шлях, ви не залишитеся без роботи і зможете користуватися всіма благами, які дарує фрілансерство.
Великі кар'єрні можливості
Широкоформатність професії Full-stack розробника дозволяє реалізувати себе в будь-якій сфері веб-девелопменту. Ви можете в будь-який момент перейти на більш вузький профіль – чисту FrontEnd або чисту BackEnd розробку (горизонтальний розвиток, поглиблення в конкретну сферу діяльності), а можете стати сильним тімлідом або архітектором, який чудово розуміється на всіх процесах створення веб-додатків і має багатий досвід за плечима (вертикальний розвиток, просування кар'єрними сходами).
Також Full-stack розробник може знайти успішне застосування своїм здібностям у стартапах. Стартап-команди, як правило, мають дуже малий бюджет і їм набагато вигідніше мати тих, хто може взяти на себе обов'язки декількох людей. Таким чином ви і новий досвід отримаєте, і зможете попрацювати над чимось свіжим, цікавим, раніше не баченим.
Ну а щодо потреб ринку в Full-stack розробниках навіть згадувати не варто – безліч компаній хоче отримати спеціаліста широкого профілю в свій штат. Кількість вакансій для них менша, ніж для фронтендників та бекендників, однак і конкуренції теж не так багато.
Мало рутини та вигорянь
Багата на різноманітність діяльність Full-stack розробників знижує ризики загрузнути в одноманітній роботі. Ви володієте великим арсеналом знань, що дозволяє вам періодично перемикатися між проєктами і менше втомлюватися від застосування одних і тих самих технологій.
Легкість у розвитку свого продукту
Ви маєте достатньо знань та вмінь, щоб самостійно створити власний проєкт. У майбутньому ви зможете організувати свою команду для вдосконалення та подальшого розвитку програмного продукту, проте вже на старті ви маєте все необхідне для того, аби реалізувати ваші ідеї.
Мінуси професії Full-stack Developer
Програш вузькоспеціалізованому розробнику на його полі бою
Full-stack девелопер володіє багатьма інструментами, але не може знати кожен настільки ж добре, наскільки окремо взятий фахівець. Ця професія передбачає подібне розпилення і унеможливлює поглиблення в будь-яку мову або технологію. Виходить, ви вмієте все, але гірше за розробника конкретного напряму.
Багато часу на навчання
Технологій, які має опанувати Full-stack спеціаліст, багато. Під час вивчення, наприклад, бекенду легко забути те, що ти вчив по фронтенду. Щоб усі знання та вміння утримувати на гарному рівні, необхідно витрачати багато зусиль. Впоратися з цим можна наступним чином: вивчаєте одну спеціальність, влаштовуєтеся на роботу, а потім вивчаєте другий напрямок. Виходить, ви не тільки поточні знання зберігаєте, але й примножуєте їх, рухаючись до фул-стек розробки.
“Нарощуйте компетенцію поступово, з невеликих завдань. Пройдіть курс із напрямку, якого вам бракує, щоб вникнути в базові принципи. А далі опановуйте знання на практиці за правилом Learning by doing” – Олексій Голубєв, Team Lead Full-stack Developer в GlobalLogic.
Важко стежити за новими тенденціями
Світ IT дуже гнучкий і мінливий. Наче імперії – виникають і руйнуються нові мови, технології, підходи в розробці ПЗ, техніки написання та ревізії коду. Вам, як фахівцю широкого профілю, необхідно знати всі новинки, адже, зрештою, цього і вимагатимуть від вас роботодавці — використання сучасних інструментів та підходів.
Занадто багато обов'язків
Роботодавці іноді починають висувати велику кількість вимог до фул-стек фахівця. Раніше згадуваний Full-stack розробник Геннадій Догаєв має таку думку щодо цього:
“Замовники хочуть звалити на одну людину надто багато. Наприклад, вже зустрічаються оголошення Node.js+React.js+React Native, тобто до веб-стеку додається ще й мобільна розробка. Це впливає на якість знань та кінцевого продукту: чим більше технологій потрібно охопити, тим більш поверхнево знаєш кожну з них. Крім того, людині не можуть подобатися всі напрямки одночасно. Мені з цього набору не дуже цікава мобільна розробка”.
Вами хочуть залатати дуже багато дірок
Фул-стек розробнику можуть часто делегувати різноманітні завдання на робочому місці. Дописати за кимось код, щось переглянути, пофіксити, доробити. Працювати замість FrontEnd/BackEnd розробника, який пішов у відпустку, – мила справа. А якщо вас найняли як альтернативу 5-ти розробникам, то й взагалі будуть тримати як раба.
Складні завдання
Ви знаєте більше інших, а значить, вам під силу розібратися з тою чи іншою важкою задачею. Принаймні так думає той, хто вам їх роздаватиме.
Велика завантаженість
Як ви вже помітили за попередніми пунктами, Full-stack розробнику не дадуть відпочити. Справ по вуха – це точний опис його стану на кожний робочий день.
Складнощі у заміні
Цей пункт одночасно є і перевагою, і недоліком. З одного боку, вам важко знайти заміну і, відповідно, вас цінуватимуть. З іншого боку, вам буде проблемно піти у відпустку, адже де взяти заміну? Тут і почнуться дзвінки у будь-який час доби, неможливість перекладання деяких завдань на інших розробників та інше.
Як стати розробником Full-stack?
Відповідь проста – оберіть найбільш близький до вас варіант професії та вивчіть необхідні технології за допомогою різних ресурсів, або підіть на курси full stack розробників. Радимо зробити свій вибір на користь освітньої IT-платформи ITVDN – тут ви зможете знайти 90% усіх потрібних вам відео курсів за будь-яким із обраних напрямків. Наприкінці статті ми залишимо корисні посилання на всі спеціальності, які допоможуть вам у вивченні ремесла Full-stack.
Наприклад, вам сподобався BackEnd-стек Python розробника – тоді вам підійдуть 2 курси за наступними спеціальностями:
FrontEnd Developer.
Python Developer.
З кожною програмою навчання ви зможете ознайомитися докладніше, перейшовши за залишеними посиланнями.
Зарплати Full-stack розробників
Відповідно до липневої зарплатної аналітики від DOU.ua (опитано 6605 українських розробників), медіанна зарплата FullStack розробників наступна:
Junior – 980 USD;
Middle – 2475 USD;
Senior – 4750 USD.
При цьому ЗП у колег по цеху – FrontEnd та Mobile розробників – приблизно такі ж. Єдині, хто помітно виділяються – BackEnd девелопери рівня Middle та Senior. Їхня медіанна оплата праці становить 2800 USD і 5000 USD відповідно, що на кілька сотень доларів перевищує зарплату фулстеккерів.
Якщо звернутися до міжнародного веб-сайту з пошуку роботи Jooble (має українське коріння), то станом на липень середня пропозиція щодо зарплати для FullStack Developer у Києві становить 114 183 грн (приблизно 3100 USD).
Відповідно до міжнародного опитування Stack Overflow Developer Survey 2023 (понад 90 000 респондентів з усього світу), річна медіанна ЗП FullStack фахівця складає 71 140 USD (приблизно 5930 USD на місяць).
Підсумки
Full-stack Developer — універсальний веб-розробник, який поєднує у собі силу FrontEnd та BackEnd напрямків. Так, спеціалізовані девелопери зроблять всю роботу краще, ніж фул-стек фахівець, проте головний коник героя цієї статті – можливість розробляти повноцінні веб-додатки самостійно, доводячи їх до повністю готового стану. Як і будь-яке інше, Full-stack ремесло має свої переваги та недоліки.
Шлях, яким повинен пройти full stack розробник з нуля досить тернистий і насичений. Проте недаремно казали класики — терпіння та праця все перетруть. Так що все у ваших руках!
Можливо, нас читають розробники Full-stack? Із задоволенням прочитаємо вашу точку зору на позиції, викладені в цій статті. Також будемо раді будь-яким питанням та зауваженням від усіх читачів!
Ну а тим, хто вирішив обрати професію Full-stack Developer, ми бажаємо бути впертими, оптимістичними і з незагасаючим вогником спраги знань в очах.
Успіхів та кодерського натхнення на вашому шляху!
Корисні посилання
Весь каталог спеціальностей: ІТ-спеціальності на ITVDN.
FrontEnd складова: відео курс за спеціальністю FrontEnd Developer.
BackEnd складова:
Python Developer
PHP Developer
ASP.NET MVC Developer
ASP.NET Core Developer
Java Developer
Онлайн навчання в групі з тренером за спеціальністю FullStack Node.js Developer.
Що повинен знати Java розробник у 2020 році?
Автор: Влад Сверчков
Язык программирования Java и ООП
Алгоритмы и структуры данных
Шаблоны проектирования
Язык запросов SQL
Технологии JDBC & Hibernate
Java Enterprise Edition и фреймворк Spring
MVC
SOLID
Модульное тестирование
Git & GitHub
Scrum
Английский язык
Выводы
Мы вновь приветствуем вас, друзья!
На этот раз в нашей рубрике “Что должен знать разработчик...” под прицелом оказался такой многофункциональный язык программирования, как Java. В современном IT-рынке область веб-разработки является очень популярной, поэтому сегодня вы узнаете, каким стеком технологий должен обладать потенциальный соискатель вакансии Java веб-разработчика. Не будем медлить - начинаем!
Язык программирования Java (“Джава”)
Опираясь на данные Stack Overflow Developer Survey (около 90 000 опрошенных респондентов), можно сказать, что язык Java входит в пятерку самых популярных. Это универсальный объектно-ориентированный язык программирования, который используется в создании различного информационного продукта:
веб-приложений (серверной части);
мобильных приложений под Android;
облачных хранилищ данных;
настольных приложений;
компьютерных игр;
программного обеспечения для банковских систем и т. д.
Java был создан компанией Sun Microsystems в 1995 году. Он достаточно быстро завоевал популярность среди программистов и стал использоваться в создании клиентских приложений и серверного программного обеспечения. Java-приложения транслируются в специальный байт-код, выполняемый виртуальной машиной JVM (Java Virtual Machine), которая может быть установлена практически на любое устройство. Это делает программы, разработанные на Java, кроссплатформенными.
Что конкретно необходимо знать? Языком Java следует владеть на достаточно хорошем уровне, поэтому и список необходимых для освоения тем будет немаленьким.
Среди обязательных базовых разделов: машинная математика, переменные и типы данных, условные конструкции, логические операции, циклические конструкции, методы, рекурсия, массивы, объекты и классы, списки, обработка исключений, суперкласс Object, обобщения (Generics), работа с памятью.
Далее идут более продвинутые темы: коллекции, карты (Map), основы вывода (IO, NIO), методы работы со строками (String, StringBuilder, StringBuffer), регулярные выражения, Date API, рефлексия, ClassLoader, аннотации, Javadoc, VarArgs, сериализация, клонирование, потоки и интерфейс Runnable, лямбда выражения, Stream API.
Стоит знать, что совокупность вышеперечисленных разделов Java + ООП парадигмы в среде джавистов именуется Java Core (от англ. “core” - ядро).
Дабы закрепить знания и не лишиться полученных навыков написания кода мы советуем вам как можно чаще практиковаться и решать прикладные задачки из интернета либо составленные самолично.
Также советуем использовать онлайн-тренажеры, например, интерактивный тренажер от ITVDN. С его помощью вы сможете потренироваться в кодинге на Java и проверить свои знания.
Объектно-ориентированное программирование (ООП)
Объектно-ориентированное программирование - это методология разработки программного обеспечения, в основе которой лежат четыре главных принципа: абстракция, инкапсуляция, наследование и полиморфизм. Поскольку Java является объектно-ориентированным языком, необходимость изучения и полного понимания ООП парадигм обязательно. Однако, есть и приятная новость: все принципы быстро и легко усваиваются во время изучения Java.
Алгоритмы и структуры данных
Понимание алгоритмов и структур данных - обязательное требование для любого программиста. Это необходимый фундамент, благодаря которому разработчик обучается написанию хорошего исходного кода путем подбора оптимальных формы представления информации и последовательности действий.
Изучив структуры данных, вы сможете управлять сложностью своих программ, делая их более доступными для понимания, а также разрабатывать высокопроизводительные приложения, которые будут рациональнее работать с памятью.
Знание алгоритмов позволит вам создавать сложные конструкции для эффективного решения широкого спектра задач на Java.
Шаблоны проектирования
Паттерны (они же шаблоны) представляют собой архитектурные конструкции, которые описывают типичные способы решения распространенных задач, возникающих в ходе проектирования программного обеспечения. Всего существует более двух десятков шаблонов, однако виртуозно ими владеть должен архитектор ПО, а не рядовой разработчик. Обычно в одном проекте используется небольшое количество паттернов, поэтому вам достаточно знать лишь самые популярные из них.
SQL
Structured Query Language - декларативный язык структурированных запросов, который создан для взаимодействия с базами данных. Особенность SQL состоит в том, что он лишь описывает необходимые компоненты и желаемые результаты, не указывая, как именно эти результаты должны быть получены.
Каждый программный продукт подразумевает работу с данными, будь то обыкновенная процедура приема данных от сервера (например, скачивание файлов) или внесение в БД информации о новом зарегистрированном пользователе - умение работать с данными одинаково важно во всех сферах разработки, разве что за исключением FrontEnd.
Также изучите одну из систем управления базами данных (СУБД). Это может быть MySQL либо PostgreSQL. Их главное отличие от SQL в том, что SQL - это язык запросов, а MySQL/PostgreSQL - реализации СУБД, имеющие свой диалект языка SQL.
XML
Extensible Markup Language - расширяемый язык разметки, с помощью которого можно структурировать данные для удобства их дальнейшей обработки. Прежде всего нацелен на использование в интернет среде и являет собой формат хранения и передачи данных на сервер. XML хорошо масштабируем, сочетает в себе простой и удобный синтаксис, а также базируется на кодировках Юникод для представления содержания документов.
JDBC & Hibernate
Java Database Connectivity - это стандарт взаимодействия Java-приложений с различными СУБД.
Простыми словами, JDBC имеет единый интерфейс, позволяющий любой Java-программе работать с любой базой данных одинаковыми методами. Для реализации этого универсального взаимодействия применяются специальные драйвера (не те, которые мы привыкли устанавливать на наши компьютеры). Как результат - программа никак не меняется от переключения с одной базы данных на другую, что дает JDBC весомую значимость в Java разработке.
Hibernate - это ORM (от англ. “Object-Relational Mapping” - объектно-реляционное отображение) фреймворк, главная задача которого отображение объектно-ориентированной модели данных в традиционные реляционные базы данных, то есть, связывание ООП с реляционной БД. Представляет собой программное обеспечение с открытым исходным кодом.
Java EE / Spring
Java Enterprise Edition - это платформа для создания корпоративных решений с помощью языка Java. Чаще всего на ней разрабатывают различные веб-приложения и веб-сервисы. Java EE включает в себя множество спецификаций (JSP, EJB, CDI, JPA, Servlet и прочие), главная задача которых состоит в обеспечении масштабируемости приложений и целостности данных во время работы системы.
Spring - популярный фреймворк с открытым исходным кодом, который используют для создания веб-приложений на Java. Он дает Java-разработчикам большую свободу в проектировании приложений, предоставляя средства решения проблем корпоративного масштаба. Является альтернативой Java EE в создании веб-сервисов. Spring имеет обширную документацию и достаточно прост в использовании.
Максимальной популярностью на данный момент пользуется именно Spring. Его лучше всего выбирать при создании небольших приложений или программ с микросервисной архитектурой. Java EE больше подходит для разработки легко масштабируемых монолитных приложений.
MVC (Model-View-Controller)
Архитектурный шаблон, который предусматривает разделение приложения на три компонента: Модель, Представление, Контроллер, что способствует реализации концепции распределения и закрепления ответственности за каждым компонентом. Данный подход позволяет упростить и ускорить разработку проектов, благодаря чему паттерн MVC широко применяется множеством разработчиков. Java EE и Spring имеют специальные MVC-надстройки, которые обеспечивают удобное использование данного шаблона.
Scala (опционально)
Строго типизированный мультипарадигмальный язык программирования. Одной из его особенностей является комбинирование стандартного ООП подхода с функциональным программированием. Scala, как правило, применяется в мощных системах с большим объемом данных и внушительным количеством пользователей. Данный язык программирования подходит для машинного обучения и анализа данных.
Scala не является обязательной к изучению для Java программистов. Однако, ее знание будет огромным плюсом на собеседовании. В дальнейшем вы сможете переквалифицироваться в полноценного Scala разработчика, имея необходимый бэкграунд, полученный во время Java разработки.
SOLID
Акроним, который обозначает пять основных принципов объектно-ориентированного программирования. Следование стандарту SOLID позволяет создавать легко поддерживаемые и масштабируемые проекты с удобной архитектурой и минимальным количеством “запахов кода”. Также знание данных принципов показывает грамотность разработчика, уровень его профессионализма. Это безусловно сыграет вам на руку на собеседовании.
Unit тестирование
Тот самый тип тестирования, который берет на себя не тестировщик, а сам программист. Идея - в написании тестов под каждую нетривиальную функцию либо метод. Цель модульного тестирования — изолировать отдельные части программы и показать, что по отдельности они являются работоспособными. Таким образом происходит проверка кода на регрессию и соответствующее обнаружение ошибок.
Git & GitHub
Git - наиболее популярная система контроля версий, которая позволяет вести историю разработки проекта с возможностью доступа к каждой сохраненной версии. В роли главного конкурента Git выступает SVN (централизованная система, в отличие от Git).
Помимо этого, стоит уметь работать с сервисом онлайн-хостинга проектов, использующих систему контроля версий. В данном случае это GitHub. В тандеме с Git он позволяет разработчикам сохранять свой код онлайн, а затем взаимодействовать с другими разработчиками в разных проектах.
Данные системы позволяют команде программистов работать над одним проектом одновременно, сохраняя внесенные изменения, а также отслеживать выполнение задач каждым членом группы.
Scrum
Методология ведения разработки программного обеспечения, которая относится к семейству гибких (Agile). Исповедует командный подход к созданию ПО, короткие итерации, частые выпуски новых версий продукта, учет изменений и непрерывное улучшение в процессе работы. Scrum применяется не только в IT, но и в производстве, маркетинге, консалтинге и прочих сферах.
Множество команд разработки ПО успешно применяют данную методологию, поэтому ее важность сложно переоценить.
Английский язык
Знание английского языка - естественное требование для каждого разработчика в IT, поскольку большинство новых сведений о технологиях, курсы, учебные и справочные материалы появляются в первую очередь на английском. Для работы в команде разработчиков обычно знаний языка на уровне чтения технической документации и комментирования кода вполне достаточно, однако если вы планируете самостоятельно вести переговоры и переписку с иностранным заказчиком, ваш уровень должен быть выше.
Выводы
Таким образом мы с вами рассмотрели основные технологии, которыми должен владеть кандидат, стремящийся занять должность Java разработчика. Сам Java уже много лет прочно удерживает высокие позиции во всевозможных рейтингах языков программирования и покидать свой пьедестал не собирается, о чем свидетельствуют следующие статистики: dou.ua (Украина), tiobe.com (Tiobe - нидерландская компания, которая занимается оценкой качества программного обеспечения), вышеупомянутый Stack Overflow Developer Survey и другие информационные ресурсы.
Несмотря на то, что в статье мы была затронута именно путь веб-разработчика на Java, данный язык успешно применяется в разработке Android-приложений (Kotlin и Objective-C), разработке объемных программных систем; также на нем можно писать настольные игры (хотя он не имеет таких инструментов создания игр, как у платформы .NET).
Java достаточно универсален и способен на практически все что угодно в руках умелого программиста. А таковым вы можете стать с помощью наших курсов, направленных на интенсивное изучение языка Java. Программа обучения предлагает 23 видео курса общей продолжительностью более 160 часов. Также ITVDN предоставляет интерактивный тренажер, с помощью которого можно отточить навыки написания кода на различных языках, в том числе и на Java.
Если вам понравилась эта статья, поделитесь информацией с теми, кому она может быть интересна. Пишите в комментариях, на какие еще вопросы, связанные с выбором специальности и планированием обучения вы хотите получить ответы. Мы постараемся ответить на них в наших новых обзорах.
Що повинен знати FrontEnd розробник у 2019 році
Автор: Влад Сверчков
Верстка сайтов и веб-программирование привлекают большое количество новичков в мир IT. Это связано с достаточно низким порогом вхождения. Количество желающих стать фронтендщиком с каждым годом увеличивается, вследствии чего растут и требования к кандидатам.
Какие технологии необходимо изучить, чтобы стать FrontEnd разработчиком в 2019 году? Давайте разберемся.
HTML5 & CSS3
HTML5 и CSS3 - это фундаментальные технологии, без знания которых не обойтись любому веб-разработчику. С помощью языка гипертекстовой разметки HTML создается разметка (каркас) каждой интернет-страницы. Затем язык стилей CSS преображает сайт и придает ему привлекательный и эффектный внешний вид.
Также необходимо владеть:
кроссбраузерной адаптивной версткой, чтобы уметь создавать сайты под мобильные устройства, планшеты и широкоформатные экраны и для различных браузеров;
семантической версткой для повышения качества разметки и улучшения поисковой индексации сайта.
Хорошее владение HTML и CSS уже позволяет заниматься версткой сайтов и начать зарабатывать деньги. Именно с этих двух базовых технологий начинается путь к профессии FrontEnd разработчика.
Bootstrap 4
Популярная HTML/CSS платформа для разработки адаптивных веб-приложений, которую применяют при создании сайтов и интерфейсов администраторских панелей. Основные преимущества Bootstrap:
высокая скорость верстки;
кроссбраузерность и кроссплатформенность;
наличие хорошей документации, большого сообщества и огромного количества разнообразных обучающих материалов;
низкий порог вхождения (необходимо знать лишь основы HTML, CSS, JavaScript и jQuery).
JavaScript
Язык программирования, который используется как при разработке клиентской стороны веб-приложения, так и серверной. При помощи JavaScript (сокращенно - JS) можно писать даже десктопные (настольные) и мобильные приложения, используя определенные программные платформы и библиотеки. Этот язык позволяет:
динамически изменять разметку;
осуществлять интерактивное взаимодействие с пользователем;
анимировать изображения;
совершать валидацию форм;
управлять мультимедиа и т. д.
Другими словами, JavaScript “оживляет” страницу и добавляет ей функциональности. Хорошее владение данным языком программирования является обязательным для каждого FrontEnd разработчика.
Сергей Росоха, Software Architect с 11-летним опыта во FrontEnd/JS, отмечает важность изучения алгоритмов и структур данных на JavaScript:
“JavaScript давно уже используется не только для разработки динамических интерфейсов пользователя, но и для написания достаточно сложной бизнес-логики. Поэтому знание алгоритмов и структур данных становится критичным для JS-разработчиков. ” (источник)
JavaScript использует официальный стандарт ECMAScript (сокращенно - ES), который подразумевает определенное формальное описание синтаксиса, базовых объектов и алгоритмов. На данный момент существует множество различных версий ES. Работодатели чаще всего требуют знание ES6.
Однако, вначале необходимо изучить чистый JavaScript и лишь потом вникать в новые стандарты. Как ни крути, а классику надо знать. Благодаря хорошему владению JS можно быстро разобраться в любой версии ES и затем освоить любой фреймворк или библиотеку.
Фреймворки JavaScript
Это инструменты, с помощью которых создаются динамические веб/мобильные/десктопные приложения на языке JavaScript. Они ускоряют разработку веб-приложений и предусматривают четко структурированную организацию кода, повышая его качество и чистоту.
Самыми популярными фреймворками для фронтенд-разработки можно назвать Vue.js, React и Angular. Каждый из них предназначен для решения своего спектра задач и имеет различную степень сложности: Vue.js - самый легкий (но и с наименьшим сообществом), React - средней сложности, Angular - высокой сложности. Стоит сконцентрироваться на глубоком изучении одного фреймворка, но в то же время очень рекомендуется знать особенности и сферу применения всех вышеперечисленных технологий.
Какой фреймворк все же выбрать? Мнения на этот счет расходятся. Инструментарий выбирается индивидуально под проект и трудно предугадать, какие задачи вам нужно будет решать. Мы рекомендуем Angular.
CSS препроцессоры
CSS препроцессор - это программа, которая имеет свой собственный синтаксис, но может сгенерировать из него CSS код. Самыми популярными считаются SASS, Stylus, LESS и PostCSS, однако, наибольшее комьюнити имеет именно SASS. Препроцессоры предназначены для:
ускорения процесса написания кода;
упрощения чтения кода и дальнейшей его поддержки;
минимизации рутинной работы при написании кода.
Для повышения эффективности написания CSS кода вполне достаточным будет изучение лишь одного препроцессора.
Git
Самая популярная распределенная система управления версиями, которая позволяет вести историю разработки проекта с возможностью доступа к каждой сохраненной версии. Таким образом, если в процессе создания программный продукт стал неправильно функционировать, есть возможность вернуться к предыдущей рабочей версии вместо длительных поисков ошибок.
Также системы управления версиями являются неотъемлемым инструментом командной разработки, который дает возможность девелоперам работать над одним проектом одновременно, сохраняя внесенные изменения. Заодно удобно отслеживать выполнение задач каждым членом команды. Очень важный инструмент для любого IT-разработчика.
jQuery
Небольшая, быстрая и многофункциональная JavaScript-библиотека, для работы с которой необходимо владеть HTML, CSS и JavaScript на базовом уровне. Она призвана упростить программирование на JS. Данная библиотека представляет объемные решения распространенных задач в виде методов, которые вызываются одной строчкой кода.
Несмотря на то, что jQuery теряет популярность, уступая место фреймворкам JS, большое количество сайтов все еще используют эту библиотеку. FrontEnd разработчик, работающий в офисе, не всегда создает новые веб-сайты - необходимо поддерживать и обновлять уже существующие. Тут без знания jQuery никак не обойтись.
JavaScript Core (DOM, AJAX, JSON)
DOM (Document Object Model) - объектное представление исходного HTML-документа. Ключевым является понятие DOM-дерева, которое описывает структуру страницы. С помощью объектной модели JavaScript получает полную власть над HTML-документом: возможность редактировать, удалять и добавлять элементы и атрибуты HTML, менять CSS код и т. д.
AJAX (Asynchronous JavaScript And XML) - это синтез технологий JavaScript и XML, который фактически представляет собой комбинацию:
встроенного в браузер XMLHttpRequest-объекта (чтоб запрашивать данные с веб-сервера);
JavaScript и HTML DOM (чтобы отображать или использовать данные).
AJAX позволяет веб-страницам совершать асинхронное обновление, обмениваясь данными с веб-сервером. Благодаря этой технологии страница не нуждается в перезагрузке - обновляется лишь конкретная ее часть (вспомните ленту новостей в социальных сетях).
JSON (JavaScript Object Notation) - это общий формат обмена данными. Позволяет совершать обмен информацией между программными продуктами, написанными на разных языках. Таким образом, клиент, использующий JavaScript, может легко передавать данные на сервер, который реализован с помощью Ruby/Java/PHP.
Все три технологии являют особую ценность для каждого веб-разработчика и раскрывают организацию работы интернет-приложения.
БЭМ
“Блок, Элемент, Модификатор” - методология, предусматривающая компонентный подход к разработке веб-страниц, в основе которого лежит принцип разделения интерфейса на независимые блоки. Подход БЭМ позволяет повторно использовать существующий код в создании других страниц с сохранением всех его свойств (размеры, шрифт, цвет и т. д.).
Webpack
Мощный сборщик модулей, который позволяет скомпилировать в один файл несколько разных модулей. Используется во время работы над объемными проектами. Успешно применяется как во фронтенд-разработке, так и при создании бэкенд-приложений.
Flex и Grid CSS
Технологии верстки надежных адаптивных веб-страниц, которые позволяют легче создавать динамические сайты и удобнее структурировать их содержимое. Лучше всего Flex-верстку в действии показывает интерактивный сайт flexboxfroggy.com, а Grid-верстку - cssgridgarden.com.
Gulp / Grunt
Системы сборки, которые автоматизируют рутинные задачи разработчиков: минификацию кода, оптимизацию изображений, тестирование, анализ качества кода и прочее. Подходят при разработке небольших проектов.
TypeScript
Кроссплатформенный строго типизированный язык, который является расширением JavaScript. Строгая типизация позволяет уменьшить количество потенциальных ошибок в исходном коде, написанном на TypeScript. Также, этот язык реализует концепции, которые близки объектно-ориентированным языкам, таким как C#, Java и подобным. TypeScript повышает скорость и удобство написания сложных комплексных программ, вследствии чего их становится легче поддерживать, масштабировать и тестировать.
SVG
Язык разметки масштабируемой векторной графики. Изображения на странице, сделанные с помощью SVG, корректно отображаются на экранах с различным разрешением, не теряя при этом своего качества, в отличии от традиционных растровых .jpeg, .png и других.
Английский язык
Знание английского языка является одним из основных требований к фронтенд-разработчику, поскольку большое количество полезной информации находится именно на англоязычных сайтах. Уровень чтения технической документации будет достаточным для комфортного пользования иностранными ресурсами.
Итоги
FrontEnd разработчик - достаточно универсальный боец в мире веб-разработки. Он должен уметь и верстать, и создавать логику работы клиентской части, и понимать работу серверной части веб-приложения. Для освоения такого обширного инструментария стоит запастись временем, терпением и упорством. Перечисленные в статье средства разработки сайтов также имеют аналоги, поскольку для решения разных задач подходят разные веб-инструменты. Однако мы выбрали самые популярные и эффективные из них.
Если у вас остались вопросы о последовательности и необходимости изучения тех или иных технологий, ответы вы можете найти в видео Как стать FrontEnd разработчиком, в котором подробно рассматриваются основные технологии создания клиентских веб-приложений.
Для тех, кто хочет стать FrontEnd разработчиком, на ITVDN создана комплексная программа обучения, которая включает в себя 35 видео курсов.
Желаем вам успехов в достижении ваших целей!
Оставайтесь с ITVDN!
Kotlin vs Java: що краще для Android-розробки?
Автор: Виджай Катри
Kotlin – это статически типизированный язык программирования, разработанный компанией JetBrains. Подобно языку Java, Kotlin стал отличным выбором для разработки приложений на Android. Это можно увидеть даже из того факта, что Android Studio поставляется со встроенной поддержкой Kotlin, как и с поддержкой Java.
Kotlin против Java
Итак, вопрос состоит в том, стоит ли разработчику переходить на Kotlin с Java или нет? Конечно это зависит от предпочтений разработчика. Однако, прежде чем переключаться, важно понять разницу между двумя языками программирования.
Проверяемые исключения
Одно из основных различий между Java и Kotlin заключается в том, что в последнем нет условий для проверяемых исключений (checked exception). Следовательно, нет необходимости отлавливать или объявлять какие-либо исключения.
Если разработчик, работающий на Java, считает, что использование кода try / catch в коде раздражает, то упущение, сделанное Kotlin, можно считать желанным изменением. Однако противоположностью будет, если разработчик считает, что проверяемые исключения нужны, способствуя восстановлению после ошибок и созданию надежного кода. В этом случае это можно считать для Kotlin плюсом и минусом, в зависимости от подхода к разработке.
Краткость кода
Сравнение класса Java с эквивалентным классом Kotlin демонстрирует лаконичность кода Kotlin. Для той же операции, что выполняется в классе Java, класс Kotlin требует меньше кода.
Например, конкретный сегмент, где Kotlin может значительно сократить общий объем стандартного кода, - это findViewByIds.
Расширения Kotlin в Android позволяют импортировать ссылку на View в файл Activity. Это дает возможность работать с этим представлением, как если бы оно было частью Activity.
Это явно можно отнести к плюсам Котлин.
Сопрограммы
Процессы, интенсивно загружающие процессор и сетевой ввод-вывод, обычно используют длительные операции. Вызывающий поток блокируется до завершения всей операции. Поскольку Android является однопоточным по умолчанию, пользовательский интерфейс приложения полностью блокируется, как только блокируется основной поток.
Традиционное решение этой проблемы в Java - создать фоновый поток для длительной или интенсивной работы. Однако управление несколькими потоками приводит к увеличению сложности, а также к ошибкам в коде.
Kotlin также позволяет создавать дополнительные потоки. Тем не менее, есть лучший способ управления интенсивными операциями в Kotlin, известный как сопрограммы или корутины (coroutines). Корутины в Kotlin реализованы без стека, что означает, что они требуют меньшего использования памяти по сравнению с обычными потоками.
Корутины могут выполнять длительные и интенсивные задачи, приостанавливая выполнение, не блокируя поток, а затем возобновляя выполнение через некоторое время. Это позволяет создавать неблокирующий асинхронный код, который выглядит в работе как синхронный.
Код с использованием корутин не только понятен, но и лаконичен. Более того, корутины позволяют создавать элегантные дополнительные стили асинхронной неблокирующей разработки, такие как async / await.
Все это также явно относится к плюсам Котлина.
Классы данных
В полноразмерных проектах обычно есть несколько классов, предназначенных исключительно для хранения данных. Хотя эти классы практически не имеют функциональности, разработчику необходимо написать много стандартного кода на Java.
Обычно разработчик должен определить конструктор и несколько полей для хранения данных, функции геттеры и сеттеры для каждого из полей, а также функции equals(), hashCode() и toString().
У Kotlin есть очень простой способ создания таких классов. Разработчику достаточно включить только ключевое слово data в определение класса, и все - компилятор сам позаботится обо всем.
Такое удобство создания классов, в вопросах для Kotlin «за и против», явно свидетельствует в его пользу.
Функции расширения
Kotlin позволяет разработчикам расширять класс новыми функциями с помощью функций расширения. Эти функции, хотя и доступны в других языках программирования, таких как C#, не доступны в Java.
Создать функцию расширения легко в Kotlin. Это делается путем добавления префикса к имени класса, который должен быть расширен до имени создаваемой функции. Чтобы вызвать функцию в экземплярах расширенного класса, нужно использовать нотацию «.»
Функции высшего порядка и лямбды
Функция высшего порядка - это функция, которая принимает другие функции в качестве параметров или возвращает функцию. Кроме того, функции Kotlin являются функциями первого класса. Это означает, что они могут храниться в структурах данных и переменных, которые могут передаваться в качестве аргументов и возвращаться из других функций более высокого порядка.
Все это просто означает, что функции могут работать всеми возможными способами во взаимодействии с другими нефункциональным значениям.
Как статически типизированный язык программирования, Kotlin использует ряд функциональных типов для представления функций. Более того, он поставляется с набором специализированных языковых конструкций, таких как лямбда-выражения.
Анонимные функции и лямбда-выражения также известны как функциональные литералы. Это функции, которые не объявлены, но передаются как выражения.
Неявные расширяющие преобразования
В Котлине нет поддержки неявных расширяющих преобразований для данных. Таким образом, меньшие типы не могут быть преобразованы в большие типы. В то время как Java поддерживает неявные преобразования, Kotlin требует выполнить именно явное преобразование.
Ряд разработчиков воспринимает это как минус Котлин.
Встроенные функции
Переменные, к которым осуществляется доступ в теле функции, называются замыканиями. Использование функций высшего порядка может существенно увеличить время выполнения вычислений. Каждая функция в Kotlin является объектом, и он захватывает замыкание.
И классы, и функторы требуют выделения памяти. Они, наряду с виртуальными вызовами, требуют определенных затрат на время выполнения. Таких дополнительных издержек можно избежать, вставив лямбда-выражения в Kotlin. Одним из таких примеров является функция lock().
В отличие от Kotlin, Java не обеспечивает поддержку встроенных функций. Тем не менее, компилятор Java способен выполнять встраивание с использованием метода final. Это так, потому что методы final не могут быть переопределены подклассами. Кроме того, вызов метода final разрешается во время компиляции.
Такие нововведения также воспринимаются как плюсы Котлина.
Встроенная поддержка делегирования
В терминологии программирования, Делегирование представляет собой процесс, в котором принимающий объект делегирует свои операции второму объекту делегата. Kotlin поддерживает шаблон проектирования композиция поверх наследования посредством делегирования первого класса, также известный как неявное делегирование.
Делегирование в Kotlin является альтернативой наследования. Этот механизм позволяет использовать множественное наследование. Кроме того, делегированные свойства Kotlin предотвращают дублирование кода.
Не-private поля
Инкапсуляция необходима в любой программе для достижения желаемого уровня управляемости.
Посредством инкапсуляции, представление объекта может быть установлено исходя из того, как вызывающие стороны взаимодействуют с ним. Кроме того, можно изменить представление без необходимости изменения вызывающих абонентов, если публичный API остается неизменным.
Неприватные поля или public поля в Java полезны в сценариях, где вызывающие объекты должны меняться в соответствии с их представлением. Это означает, что такие поля предоставляют представление объекта вызывающим объектам. У Kotlin нет не-private полей.
Это достаточно интересное отличие при сравнении Kotlin и Java.
Нулевая безопасность
Одной из самых заметных проблем для разработчиков, связанных с Java, является NullPointerExceptions. Java позволяет разработчикам присвоить значение null любой переменной. Однако, если они пытаются использовать ссылку на объект с значением null, возникает исключение NullPointerException!
В отличие от Java, в Kotlin все типы по умолчанию являются не-nullable. Если разработчики попытаются присвоить или вернуть значение null в коде Kotlin, во время компиляции произойдет сбой. Тем не менее, есть способ обойти этот момент. Чтобы присвоить значение null переменной в Kotlin, необходимо явно пометить эту переменную как nullable. Это делается путем добавления знака вопроса после типа, например:
val number: Int? = null
Таким образом, в Kotlin нет исключений NullPointerException. Если вы встречаете такое исключение в Kotlin, то, скорее всего, вы либо явно присвоили значение null, либо это связано с каким-то внешним Java-кодом.
Примитивные типы
Существует 8 примитивных типов данных, включая char, double, float и int. В отличие от Kotlin, переменные примитивного типа не являются объектами в Java. Это означает, что они не являются объектами, созданными из класса или структуры.
Умные приведения
Прежде чем объект может быть приведен в Java, обязательно нужно проверить тип. Это также верно в сценариях, где очевидно нужно приводить объект.
В отличие от Java, Kotlin имеет функцию умного приведения, которая автоматически обрабатывает такие избыточные приведения. Вам не нужно выполнять приведение внутри оператора, если он уже проверен оператором is в Kotlin.
Статические Члены
В Kotlin нет статических элементов. Однако в языке программирования Java ключевое слово static отражает то, что конкретный член, с которым используется это ключевое слово, принадлежит самому типу, а не экземпляру этого типа.
Это просто означает, что один и только один экземпляр этого статического члена создается и используется всеми экземплярами класса.
Поддержка Конструкторов
Классы Kotlin, в отличие от классов Java, могут иметь один или несколько вторичных конструкторов, в дополнение к первичному конструктору. Это делается путем включения этих вторичных конструкторов в объявление класса.
Троичный оператор
В отличие от Kotlin, Java имеет тернарный оператор. Тернарный оператор в Java работает как базовый оператор if. Он состоит из условия, которое оценивается как истинное или ложное.
Кроме того, тернарный оператор в Java имеет два значения. Только одно из них возвращается в зависимости от того, является ли условие истинным или ложным. Синтаксис для тернарного оператора Java:
(состояние) ? (значение 1) : (значение 2)
Типы подстановочных знаков
В общем коде, ' ?' представляет неизвестный тип. Этот символ известен как подстановочный знак. Существует несколько вариантов использования подстановочного знака, в том числе в качестве типа поля, локальной переменной или параметра.
В то время как система типов Java предлагает использовать подстановочные знаки, в Kotlin их нет. Тем не менее, у него есть два других механизма - вариативность на уровне объявления и проекции типов как альтернатива.
Этого будет полезно учитывать при переходе с Java на Kotlin.
Библиотеки обработки аннотаций с Kotlin
Помимо предоставления поддержки существующим Java-фреймворкам и библиотекам, Kotlin также предлагает расширенные Java-фреймворки, основанные на обработке аннотаций.
Однако применение в Kotlin библиотеки Java, которая использует обработку аннотаций, требует добавления ее в проект Kotlin немного другим способом, чем требуется для библиотеки Java, которая не использует обработку аннотаций.
Требуется указать зависимость с помощью плагина kotlin-kapt. После этого необходимо использовать инструмент обработки аннотаций Kotlin вместо annotation Processor.
Все еще в замешательстве? Вот решение - взаимозаменяемость!
Очевидно, что некоторые моменты лучше реализованы в Kotlin, в то время как для других - выгодно использовать Java. Для тех, кто не хочет отказываться от любого из двух ведущих языков программирования для разработки под Android, к счастью, есть и другой путь.
Независимо от всех различий между двумя языками программирования, они полностью совместимы. И Java, и Kotlin компилируются в байт-код. Это означает, что в вопросах «Kotlin vs Java» не будет однозначного ответа, ведь можно вызывать код Java из Kotlin и наоборот.
Эта гибкость имеет два преимущества. Во-первых, это облегчает начало работы с Kotlin, постепенно добавляя код Kotlin в проект Java. Во-вторых, оба языка могут использоваться одновременно в любом проекте разработки приложений для Android.
Подводя итоги
Несмотря на значительные плюсы Kotlin, в вопросах разработки общего назначения Java одерживает верх. С другой стороны, все больше разработчиков и организаций внедряют Kotlin для быстрой разработки Android приложений.
И Java, и Kotlin имеют свои преимущества друг перед другом. Дискуссия о том, какой из них подходит для разработки лучше, только началась, и вряд ли она закончится в ближайшее время. Вопросы выбора: «почему Java?», «почему Kotlin?» все еще остаются. В любом случае переход с Java на Kotlin не будет болезненным.
С нашей стороны, мы хотели бы предложить комплексную программу подготовки Java разработчика, которая включает в себя видео курсы по Java и сопутствующим технологиям. Тем же, кто хочет познакомиться с основами языка Kotlin – ITVDN.com предлагает ознакомиться с курсом Kotlin.
Источник
Популярні PHP MVC фреймворки
Автор: Редакция ITVDN
Автор статьи: Влад Кобылянский, архитектор программного обеспечения, разработчик и консультант по технологиям малого бизнеса (Майами, Флорида).
Вопрос: Что сегодня происходит с PHP фреймворками?
В феврале 2017 года я так ответил на этот вопрос:
«В основном все крутится вокруг двух PHP фреймворков - Laravel и Symfony. Особой нужны в использовании CakePHP, Zend, CodeIgniter, Yii и т. д. нет, если вы начинаете новый проект. Только если вы уже знаете эти фрэймворки или у вас в команде есть разработчики которые привыкли работать с ними, тогда причины их использования обоснованы.
Когда начинается реальная разработка, вы должны иметь возможность находить инструменты, плагины, ответы на общие проблемы. С сообществами Laravel и Symfony, с постоянным развитием новых «модулей» или функций, не будет ощущения, что вы остались «в стороне». Одни Laracast (даже если вы не работаете в Laravel) чего стоят! Они просто фантастичны.
Когда заходит речь об интеграции с iron.io или другими SaaS сервисами, поддержке широкого спектра источников данных или о среде разработки – Laravel и Symfony и их расширения намного более продвинуты.
Еще одним достоинством Lumen, является быстрая разработка и прототипирование API для Laravel. При этом это никак не ограниченно для построения больших приложений.Вообще говоря, сегодня мы определенно видим переход к контейнерной архитектуре, где MVC играет гораздо меньшую роль. Все это касается микросервисов, оркестровки и создания приложений как «функций» (AWS Lambda и подобных сервисов). Возможно, пришло время освежить наши навыки Node/JS и GoLang?»
Хотя я в целом доволен этим ответом, сейчас я думаю, что некоторые моменты пришло время пересмотреть.
Прежде чем перейти к таким странным темам, как GoLang, давайте взглянем на тенденции PHP MVC фреймворков.
Я бы сказал, что тенденции, которые мы наблюдали в прошлом, остаются. Laravel продвигается вперед, в то время как большинство остальных фреймворков отстает. В популярности Symfony наблюдается небольшой всплеск, вероятно, из-за долгожданного выпуска Symfony 3. Я попробовал более конкретные поиски для сравнения, такие как «CakePHP 3» или «ZF2», однако они не привели к статистически значимым тенденциям.
На этот раз я добавил CodeIgniter, потому что он оказалася очень популярным. Я получил ряд вопросов о CodeIgniter. Если коротко, CI сейчас не в конкуренции, потому что это не 100% фреймворк MVC. Иначе, чем организованной коллекцией POPO, я это не назову.
Для наглядности представляю вам цитату из руководства CodeIgniter:
«CodeIgniter имеет довольно свободный подход к MVC, поскольку не требуются Models. Если вам не нужно дополнительное разделение или вы обнаружите, что поддерживающие Models требуют большей сложности, чем вы хотите, вы можете их проигнорировать и создать свое приложение с помощью Controllers и Views.»
Когда дело доходит до построения структуры, я просто не согласен с таким подходом. Возможно, это достойный шаблон (отсюда и популярность CodeIgniter), однако должна быть какая-то дисциплина, навязанная фреймворком, иначе конечный продукт в итоге превращается в беспорядочный спагетти-код, завернутый в какой-то «шаблон».
Далее, Symfony 3 привнес некоторые достойные улучшения в разработку и целый ряд новых «фич». Как и многие аналоги PHP, теперь он предлагает микро-фреймворк. ZF3, к примеру, добавил ряд улучшений, таких как поддержка PHP7 (наконец!) и даже стал микро-фреймворком... но, в их руководстве так и говорится:
«Для пользователей Zend Framework 2 MVC, различия с ZF3 незначительны...»
Я действительно надеялся, что они скажут, что различия есть, что было замечательное архитектурное усовершенствование, замечательные новые модули, которые помогают вам разрабатывать все по-современному. Но, увы, по большей части ZF3 по-прежнему похож на ZF2.
Long Story Short
Вот как я вижу мир PHP фреймворков сегодня:
Symfony или Laravel (выбор зависит от того, какую задачу вам нужно решить)
Все остальное
Laravel на первом месте. Объем доступной информации, Laracasts, таланты разработчиков во всем мире, простые реализации шаблонов, интегрированные наборы инструментов тестирования, активная реализация записей в форме Eloquent, облегченная версия в Lumen, развитие Homestead (Vagrant) – все перечисленное способствует фреймворку действительно выделяться и для новых, и для опытных разработчиков.
Однако модели Eloquent могут стать непослушными и довольно большими по размеру, а сервисов Laravel (не путать с микросервисами) можно создать очень много, и вот тут люди начинают думать о реализации Repository, которому здесь не место. Так родился Monolith.
Если вам не нравится активный шаблон записи и вам нужна дополнительная гибкость в репозиториях, или, возможно, вы видите слишком много независимых анонимных функций, тогда используйте Symfony + Doctrine. Рассматриваю ли я Symfony как шлюз для монолитных приложений? В какой-то степени, да.
В целом, я бы не назвал это резким изменением с прошлого года. Тем не менее, нам нужно взглянуть на общую картину: правильно разработанное приложение выходит за рамки чистого MVC; речь идет об инфраструктуре, конвейере развертывания, разъединённой архитектуре. Все это может быть достигнуто в стеке MVC, но нужно быть внимательным, чтобы избежать Monolith.
Приход микросервисов
Раньше я упоминал о распространенности микросервисов и необходимости улучшать навыки GoLang или Node. А в статье о PHP MVC было бы глупо не упомянуть о явно растущем движении к микросервис-ориентированной архитектуре (MOA); и это движение набирает обороты, поверите вы или нет.
Хотя эти два понятия не являются взаимоисключающими, не нужно находить параллели между ними, ведь они действительно представляют собой разные философии. В качестве примера, размещение вашего приложения MVC в одном контейнере и MySQL в другом, а затем объединение их вместе, не обязательно представляет собой надлежащую MOA.
Это, безусловно, лучший подход, чем пытаться установить MAMP, XAMPP или что-либо еще, чтобы заставить ваш компьютер работать с приложением.
Кроме того, это может решить некоторые проблемы, такие как простота запуска локальной среды на разных платформах и, возможно, в некоторых случаях стратегии развертывания, но вы застрянете с монолитным MVC в вашем приложении/контейнере.
Уничтожение Monolith
Микросервисы – это как раз о «разрушении». В то время как MVC обращается к вашей структуре кода и организации, обеспечивая надежный подход к разделению проблем, эта концепция еще больше расширяется контейнерами/сервисами/MOA.
Вместо того, чтобы просто отделять виды (Views) от моделей (Models), вы теперь разделяете каждый «кусок» или логическую единицу вашего приложения на индивидуальную службу, предназначенную для правильной работы с собственными обязанностями.
Если у вашего MVC-приложения есть контроллер «Поиск», действия и соответствующие методы модели, то у нас уже есть пример монолитного приложения.
Напротив, используя подход MOA, у нас будет сервис для каждого из этих процессов. В качестве примера:
Router сервис
Request сервис
Query сервис
DataSource сервис
Response сервис
Но не все эти «сервисы» являются частью стека MVC? Конечно нет. Они являются строительными блоками нашего Monolith.
С MOA каждый сервис работает в рамках собственной среды, а мы, как архитекторы, можем разработать лучший подход к решению конкретного запроса.
В качестве примера, если я должен был бы написать службу обработки изображений в среде Laravel, я использовал бы что-то вроде расширения PHP-GD2, что может быть не самым эффективным способом обработки изображений. Служба C++, которая обрабатывает мои запросы в обработке изображений, может быть намного быстрее и определенно более надежной при масштабировании. И мы могли бы сделать вывод службы обработки изображений и отправить ее в службу DataStore, службу CloudStorage и службу Queue Email.
Решение этой же задачи с кучей скрытых заданий и, возможно, нескольких отдельных приложений MVC и пользовательских сценариев – это то, как разработчики делали это раньше (2 года назад). Время двигаться вперед.
Масштабируемость
Здесь возникают проблемы (или заканчиваются, в зависимости от того, куда вы держите курс). С одной стороны, очень сложно масштабировать Monolith: если вы создадите все больше и больше логики в одном и том же наборе MVC, вы застрянете с хорошо структурированным приложением ужасной сложности. С другой стороны, если вы построите тысячу микросервисов на разных языках, как вы будете управлять этим беспорядком?
Существуют различные инструменты компоновки контейнеров (например, Kubernetes, Swarm, Mesos), услуги по развертыванию контейнеров (GKE и AWS ECS), однако лишь немногие предприятия используют архитектуру Docker. Есть удачные истории в построении инфраструктуры с использованием Docker или других контейнерных технологий (т. е. GKE). Большинство из этих историй исходят от компаний, которые могут позволить себе тратить ресурсы на архитекторов, дефолтов, администраторов баз данных и инженеров. Тем не менее, сейчас идут бесчисленные дискуссии о том, как развернуть хорошо организованный и элегантный MOA.
В любом случае, вы не решите эту проблему самостоятельно, и пока вы не достигнете относительно большого масштаба, эта проблема действительно нуждается в решении. Может быть, сейчас не самое время усердствовать.
Золотая середина на сегодняшний день (даже для тех, кто занимается приложениями меньшей сложности или не такими требованиями к трафику) заключается в том, чтобы разгрузить многие типичные сервисы сторонним провайдерам. Почти все доступно сейчас как сервис. Фоновые задания, обработка изображений, аутентификация, аналитика данных, ведение журнала, отправка электронной почты, системы очереди не обязательно должны строиться в одном стеке MVC, а архитектор должен подумать о том, что может быть выгружено в систему SaaS за небольшую ежемесячную стоимость (т.е. поиск Algolia) или, возможно, специально созданную докерную службу, работающую в облачном пространстве, которая выполняет эту обработку изображений.
Я думаю, важно, чтобы вы не начали перепроектировать весь проект с начала, не сбрасывать все, что у вас уже есть, а выпускать докеры, где это можно сделать. Существуют способы постепенного развертывания вашего проекта/продукта путем разъединения, изучения узких мест в системе (и т.д.) и последующим применением разделения проблем в этих проблемных областях.
Вывод
2017 год принес нам много дискуссий и производственных развертываний, основанных на контейнерах и MOA. Мои размышления о Docker, используя GoLang или Node, не означают, что PHP «умирает» или что-то в этом роде ... Я считаю, что разработчикам нужно оставаться в тренде. Если микросервисы и дальше будут развиваться в том же русле, в котором это происходит сейчас, то почему бы не изучить GoLang? Он идеально подходит (из-за низкой занимаемой площади, скорости и параллельной обработки) для разработки небольших контейнерных приложений. Node и GoLang позволяют создавать небольшие сервисы, которые являются частью более крупного проекта, связывают созданные сервисы и выпускают их как контейнеры Docker, если это необходимо в вашей работе.
Тем не менее, все эти передовые решения и языки не уменьшают значимость и востребованность языка PHP. Разработчикам еще нужны будут стеки MVC и работа с API.
MOA пока не помогает решить архитектурные проблемы на стороне frontend, UI или Views, хотя при этом контейнеры помогают нам избежать работы с Monolith на backend. Мы можем создать чрезвычайно надежное backend-приложение, но оно среагирует на JSON, который каким-то образом должен быть представлен в клиентском приложении. Имеет ли значение, если результирующий объект ответа поступает из РНР кода, URL или от модулей принятия решений и обработки, разделенных интерфейсом обмена сообщениями? Это зависит от Ваших потребностей и требований к вашему приложению.
Мой совет: в этом году учите Laravel, следите за Docker, GoLang и фокусируйтесь на конвейере развертывания. Продвижение от локального небольшого проекта к продакшену должно быть достаточно плавным, особенно при создании приложений MVC.
Оригинал статьи
Введення в розробку програм під iOS. Частина 5
Автор: Volodymyr Bozhek
Здравствуйте, дорогие читатели.
В этом уроке мы научимся:
Добавлять иконку приложения;
Добавлять картинки в приложение. Разберем, как пользоваться “Assets”.
Откройте проект “Warehouse”.
В панели навигатора откройте модуль “Assets.xcassets”.
Нажмите “App Icon”, вы увидите область с контейнерами для добавления иконок приложения.
На рисунке выше нас интересуют два контейнера “iPhone App iOS 7-10 60pt”, тут задается иконка приложения.
В разделе “iPhone Notification iOS 7-10 20pt” задается иконка, которая будет отображаться при получении “Push” уведомлений от вашего приложения в заголовке сообщения.
В разделе “iPhone Spotlight – iOS 5,6 Settings – iOS 5-10 29 pt” задается иконка приложения, которая будет отображаться в диалоге поиска вашего телефона (если приложение под iOS 5 или 6) и в настройках телефона.
В разделе “iPhone Spotlight iOS 7-10 40pt” задается иконка, которая будет отображаться в диалоге поиска вашего телефона.
Теперь давайте разберем, что означают метки “2х” и “3х”. Метки- это размер иконок.
Например, ваша исходная иконка имеет размер “16х16”, для нее будет задана метка “1х”. Соответственно, для метки “2х” будет размер “32х32” (16+16 x 16+16), т.е. в два раза больше исходной иконки под меткой “1х”. Для метки “3х” будет размер “48х48” (16+16+16 x 16+16+16), т.е. в три раза больше исходной иконки под меткой “1х”.
Принято именовать иконки следующим образом:
Иконка с меткой 1х используется для iOS ниже 7 версии. Вам ее не нужно делать, так мы используем язык программирования “Swift” в нашем приложении и доступен он, только начиная с версии “iOS 8”, не ниже. В “iOS” ниже версии 8 доступен для использования язык программирования “Objective C”, его я не буду разбирать вообще, поскольку у него не удобочитаемый синтаксис и для новичков он будет сложным. Т.е., должно быть в таком формате “[Имя исходной иконки][Размер в “pt”][Метка].[Расширение файла иконки]”.
Таблица с размерами и метками иконок для раздела “iPhone Spotlight – iOS 5,6 Settings – iOS 5-10 29 pt”:
Таблица с размерами и метками иконок для раздела “iPhone Spotlight iOS 7-10 40pt”:
Таблица с размерами и метками иконок для раздела “iPhone App iOS 7-10 60pt” (иконка нашего приложения):
Таблица с размерами и метками иконок для раздела “iPhone Notification iOS 7-10 20pt”:
Итак, приступим к созданию нашей иконки. Скачайте файл “warehouse.png” (размер 512х512) ниже на странице себе на компьютер.
Откройте любой графический редактор, которым умеете пользоваться и создайте файлы иконок в соответствии с 4 разделами, приведенными выше в таблицах. Имена файлов должны соответствовать тем, что в 4 таблицах выше.
Как пользоваться графическим редактором, рассматривать не стану. Под OS X есть бесплатный графический редактор “Gimp”, есть платный “Adobe Photoshop”.
После обработки данного файла в графическом редакторе должны получиться на выходе следующие файлы:
Отлично с этим справились, теперь необходимо перетащить из “Finder” иконки “*.png” в соответствующие места в “App Icon” по разделам. Выполните это, должно получиться вот так:
Теперь закройте проект “Warehouse” и откройте его снова. Обратите внимание на иконку приложения, которая появилась в панели инструментов.
Запустите приложение. Затем выполните комбинацию клавиш “Shift + Command + H”, чтобы выйти на рабочий стол устройства. Обратите внимание на иконку приложения “Warehouse”, она тоже изменилась.
А вот так она выглядит в диалоге поиска “Spotlight”:
Теперь разберем, как добавлять картинки в ресурсы и отображать их в элементах управления. Тренироваться будет на списке товаров.
Прилагаю список картинок, которые мы будем использовать в ресурсах.
Скачайте эти картинки, затем выделите весь список. Откройте модуль “Assets.xcassets” и перетащите из “Finder” в пустую область под “App Icon” выделенный список загруженных картинок. Должно получиться вот так:
Все бы хорошо, если бы только не нововведения для картинок, начиная с iOS 10 и Xcode 8. До iOS 10, добавляя картинки подобным образом в ресурсы, все без проблем загружалось в AppStore. Но вот начиная с iOS 10, было принято, чтобы картинки были в двух разных форматах “sRGB” и “Display P3”, предпринято это было для возможности управления насыщенностью цветов. Более подробную информацию, как к этому пришли, можно получить, изучив “WWDC 16, Session 712, Working with Wide Color, Understanding and optimizing for Wide Color Gamut Displays”.
Если использовать версию среды разработки, например, Xcode 7.3.1, то в ней с минимальной версией приложения iOS 8.0 не надо делать никаких конвертаций с картинками, все без проблем загружается в AppStore. Если же загружать без конвертации “sRGB and Display P3” со среды разработки “Xcode 8”, то на этапе валидации мы получим ошибку “Invalid Bundle. The asset catalog at '$path' can't contain 16-bit or P3 assets if the app is targeting iOS releases earlier than iOS 9.3”.
Да, с одной стороны можно было поставить минимальную версию iOS 9.3, ничего не конвертировать и отправить приложение в AppStore, но тогда бы я потерял пользователей, у кого iOS 8, 8.1, 8.2, 8.3, 9, 9.1, 9.2, 9.2.1. Пришлось разбираться, как это исправить, чтобы выполнить загрузку в AppStore, и при этом минимальная версия так и осталась iOS 8.
Для конвертации изображений в OS X есть специальная бесплатная встроенная утилита “ColorSync Utility”. Картинки, которые я показывал выше, имеют формат “RGB”, чтобы убедиться в этом. В “Finder” выполните клик правой кнопкой мыши на картинке, например, “tool001.png” и в контекстном меню выберите пункт “Get info”.
Обратите внимание на свойство “Color space”, его значение “RGB”. Создайте где-нибудь две папки с названиями “Tools_sRGB” и “Tools_Display_P3”. В эти папки мы будем складывать сконвертированные картинки.
Картинка формата “Display P3” (16 битная) будет автоматически подгружаться, если у пользователя iOS 10, если же у пользователя версия операционной системы ниже iOS 10, будет браться картинка формата “sRGB” (8 битная).
Если вы добавите только картинки в формате “sRGB”, тогда, если у пользователя операционная система iOS 10, эти картинки будут каждый раз конвертироваться из формата “sRGB” в формат “Display P3”. Добавить только картинки формата “Display P3” и не добавить картинки формата “sRGB” нельзя, надо или в обоих форматах, или только в формате “sRGB”.
Если вы обратили внимание, когда добавляли картинки в “Assets.xcassets”, а затем выделили одну из добавленных картинок, с правой стороны от нее был отображен контейнер “Universal”. Давайте включим поддержку “Display Gamut”. Выделите “tool001.png”, в панели свойств откройте вкладку “Show the attributes inspector”. Найдите свойство “Gamut”, в нем сейчас установлено значение “Any”, установите значение “sRGB and Display P3”.
Перейдите в “Finder”, теперь мы должны сконвертировать исходные загруженные картинки в два формата “sRGB” и “Display P3”. Для этого в “Finder” выделите картинку “tool001.png”, выполните по ней клик правой кнопкой мыши и в контекстном меню выберите “ColorSync Utility.app”.
В открывшемся приложении “ColorSync utility”, внизу в выпадающем списке, измените значение “Match to Profile” на “Assign Profile”. Затем нажмите на выпадающий список “None” и выберите “Display”, затем “sRGB IEC61966-2.1”.
Кнопка “Apply” станет активной, нажмите на нее, затем закройте окно ColorSync “tool001.png”, нажав на красную кнопку в правом верхнем углу окна. Вам будет предложено сохранить изменения. Сохраните изменения.
Теперь перейдите в папку “Tools_sRGB”, которую мы создавали ранее, и выделите файл “tools001.png”, нажмите на нем правой кнопкой мыши и в контекстном меню выберите пункт “Get info”.
Обратите внимание на свойство “Color profile”, оно теперь имеет то значение “sRGB IEC61966-2.1”, которое мы устанавливали через утилиту “ColorSync”.
Теперь проделайте такую же операцию, еще раз с исходным файлом изображения “tool001.png”, но на этот раз выберите “Color profile” - “Display P3”.
Нажмите кнопку “Apply” и закройте окно ColorSync “tool001.png”, сохраните изменения в папку “Tools_Display_P3”. Затем откройте “Finder”, перейдите в папку “Tools_Display_P3”, выделите файл “tool001.png”, нажмите на нем правой кнопкой мыши и в контекстном меню выберите пункт “Get info”.
Обратите внимание на свойство “Color profile”, там установлено значение “Display P3”. Теперь перейдите в Xcode, откройте модуль “Assets.xcassets”, выделите изображение “tool001” и перенесите из “Finder” картинки в контейнер. В поле “1x sRGB” перетащите картинку “tool001.png” из папки “Tools_sRGB”. В поле “1x Display P3” перетащите картинку “tool001.png” из папки “Tools_Display_P3”. Должно получиться вот так:
Остальные картинки сконвертируйте самостоятельно в форматы “sRGB” и “Display P3” по той же схеме, что мы делали выше.
Ниже вы можете скачать две сконвертированные картинки.
Также добавим в “Assets” еще картинку фона страницы авторизации.
Она имеет размер “750х1334” и называется “warehouse-view.png”. Картинку тоже необходимо сконвертировать в два формата “sRGB” и “Display P3”.
В панели навигации откройте модуль “Main.storyboard”, найдите View с именем “View Controller”, из панели компонентов перетяните на View компонент “ImageView”.
Растяните его на всю область View. Нажмите кнопку “Pin” и задайте такие ограничения:
Нажмите кнопку “Add 4 Constraints”. Измените цвет кнопки “Вход” на оранжевый, цвет текста “Нет ошибок” на белый.
Откройте модуль “SuppliesViewController.swift”. Обновите модель “supplies”, как показано ниже (заполнены свойства “productImage”):
Обновите метод “cellForRowAt indexPath”:
Тут изменения только на 92 строке, в ячейке есть встроенный компонент “ImageView”, мы обращаемся к его экземпляру и от него инициализируем свойство “image”. В инициализаторe “UIImage” мы задаем аргумент “named”, название “Image Set” из “Assets”.
Запустите приложение.
На этом мы завершаем данный урок. Большой получился урок, но тему “Assets” надо было обязательно рассмотреть, чтобы в будущем к ней уже не возвращаться.
В следующем уроке мы рассмотрим, как работать с библиотекой “Alamofire” и интегрируем ее в наше приложение. Создадим тестовый сервер, в который добавим таблицу пользователей для авторизации, а в последующих уроках переведем работу списка продуктов на сервер и перепишем клиент на интеграцию с сервером.
Міфи про програмування та програмістів
Автор: Влад Сверчков
Миф 1. Без знания математики дверь в программирование закрыта
Миф 2. “Прочту книгу — стану программистом”
Миф 3. Чтобы освоить программирование, необходимо быть очень умным
Миф 4. Необходимо обладать талантом к написанию кода
Миф 5. Программисты — замкнутые и необщительные люди
Миф 6. Программирование — скучное занятие
Миф 7. Программисты всё пишут с нуля
Миф 8. Чтобы устроиться на работу в качестве программиста, необходимо очень долго учиться
Миф 9. После курсов у вас сразу высокая ЗП
Миф 10. “Выучи язык программирования… за 1 час!”
Миф 11. Нельзя освоить программирование самостоятельно
Миф 12. Программисты разбираются во всём, что связано с техникой
Миф 13. Программирование — мужское занятие
Миф 14. Существует самый-самый лучший языка программирования
Миф 15. Разработчики компьютерных игр — самые богатые и счастливые люди в IT
Миф 16. Начинающим айтишникам устроиться на работу невозможно
Миф 17. Пойду в ВУЗ, там меня научат программированию
Миф 18. Программирование имеет возрастные ограничения
Миф 19. Программист — вымирающая профессия: роботы заменят этих специалистов
Итоги
Приветствуем вас, друзья!
При своей относительной молодости программирование успело обзавестись приличным количеством мифов. Время, когда писателей кода считали дикими отшельниками, потихоньку уходит. Однако, и по сегодняшний день многие имеют ложные представления о программировании.
Некоторые считают, что программист - это человек, который взламывает компьютерные системы, банкоматы и совершает прочие несогласованные с буквой закона действия. Другие уверены: программист и компьютер тебе починит, и Windows переустановит, и ТВ-каналы настроит, и новый Фейсбук за ночь напишет, и покажет, как генерировать содержание документа в Ворде.
Более того, некоторые стереотипы настолько прижились, что стали отпугивать новичков в IT и мешать их профессиональному дебюту в данной сфере.
Мы подготовили для вас рейтинг самых главных мифов, которые необходимо развеять в первую очередь. Давайте же приступим к их разрушению.
Миф 1. Без знания математики дверь в программирование закрыта
Одно из самых распространенных заблуждений. Как мы уже упоминали в статьях “Нужно ли программисту высшее образование?” и “FAQ начинающего программиста”, важно не столько знание математики напрямую, сколько само математическое мышление. Сейчас мы все объясним.
Для того, чтобы начать изучение любого популярного языка программирования (ЯП), с головой хватит знаний школьной алгебры. Согласно опросу Stack Overflow Developer Survey 2020, более 50% разработчиков-респондентов написало свою первую строку кода до 16 лет, а в этом возрасте никто еще не изучает высшую математику. Значит, сделать старт в программировании может любой, кто учился/учится в обыкновенной среднестатистической школе.
Это первая ступенька на пути к качественному овладению ЯП. Когда вы начнете более-менее ориентироваться в языке и поднабьете руку на практических задачках, вам необходимо будет изучить смежные с математикой дисциплины: теорию множеств, графов, автоматов, алгоритмов, базовую логику. Это программа первых курсов технических вузов по IT-направлению, однако и самостоятельное ее освоение — вполне подъемная задача. При этом наименее зависимыми от математики являются такие специальности, как верстальщик и FrontEnd разработчик.
Хорошие знания в области высшей математики необходимы тем, кто хочет реализовать себя в таких направлениях: научная область, шифрование, машинное и глубокое обучение, Data Science, разработка искусственного интеллекта и все, что связано с большими данными. Именно там находит широкое применение тот мат. аппарат, которым славятся технические вузы.
Математика в программировании — это, прежде всего, о математическом и аналитическом мышлениях, которые тесно связаны с критическим мышлением и позволяют абстрагироваться, развязывать задачи с умелым применением логики. Именно правильный взгляд и рациональный подход к решению задач является главным оружием программиста, поскольку программирование — это динамика, в то время, как формулы, теоремы и аксиомы статичны. С развитием мат. мышления вам помогут различные книги, а также практика — кодинг, решение математических задачек и прочие упражнения, которые можно найти на просторах интернета.
Кстати, критическое мышление отлично развивают шоу с фокусниками. Посмотрите их, подумайте над тем, как маэстро смог провернуть тот или иной трюк (затем посмотрите соответствующие разоблачения). Также будут полезны детективные игры в стиле “Шерлока Холмса”, где, казалось бы, мистическим событиям находяться вполне логические объяснения. Умение не принимать всю информацию как чистую правду, а смотреть на нее со всех возможных углов — очень полезный навык не только в кодинге, но и в повседневной жизни.
В любом случае, данный миф о математике разрушен, а это означает, что начать программировать вы можете прямо сейчас.
Миф 2. Можно стать программистом, просто прочтя одну или несколько книг (“Прочту книгу — стану программистом”)
Программирование — это в большей степени практика. Теория здесь обязательно должна подкрепляться добротным кодингом. Это обеспечит закрепление полученной информации, а также будет гарантировать понимание вами материала и способствовать развитию ваших навыков написания кода. Поэтому чтение книг начинающими программистами должно обязательно сопровождаться соответствующими отработками (практикой), иначе получите ноль пользы от литературы и только зря потратите свое время, не достигнув желаемого.
Миф 3. Чтобы освоить программирование, необходимо быть очень умным
Миф, который отпугивает множество потенциальных программистов. Появился он из-за ложного убеждения, мол, программисты — это сверхразумы, которые видят мир, как в “Матрице” — в форме бесконечно бегущих зеленых символов. На самом деле они обыкновенные люди. Просто они горят кодом.
Программистам нравится создавать компьютерные программы, веб-сервисы, игры, мобильные приложения. Точно так же экстремалам-байкерам нравится выделывать различные трюки на железном коне, знатокам поварского дела — готовить вкусные и красивые блюда, летчикам — поднимать в воздух многотонные крылатые гиганты, водителям — колесить по бескрайним просторам, психологам — помогать людям понимать себя.
Если посмотреть на каждую профессию со стороны, в каждой можно найти свои сложности. И каждое препятствие преодолевается прежде всего большим трудом и упорством. А мозги — это часть организма, которая поддается прокачке, как и мышцы тела. Поэтому если вы чувствуете, что “недостаточно умны” для программирования, начинайте ломать этот барьер, работайте над собой и ни в коем случае не позволяйте каким-либо предубеждениям вставать у вас на пути. Никто этот шаг за вас не предпримет, так что все в ваших руках.
Миф 4. Необходимо обладать талантом к написанию кода
Успех программиста как такового обусловлен его заинтересованностью выполняемой задачи, количеством специализированных знаний, степенью владения ЯП и математическим мышлением, а также прилагаемыми усилиями. Таланта или какого-то дара в перечне нет. Так что программирование — это 95% усердной работы. Не ожидайте манны небесной — работайте, трудитесь и тогда вы сможете преуспеть в создании кода.
Миф 5. Программисты — замкнутые и необщительные люди
Возможно, в далеком прошлом это и было правдой, однако сейчас все совершенно по-другому. Более того, одними из главных требований к личным качествам программистов сегодня являются коммуникабельность, открытость и умение работать в команде. Время компьютерных гиков-одиночек кануло в Лету.
Различные конференции, хакатоны, совместный отдых и развлечения — эти вещи как-то мало совместимы с замкнутостью и необщительностью, вы не находите?
Такой спектр коммуникабельности не всегда можно встретить в фирмах, которые специализируются на коммуникациях с клиентами, а тут целые мероприятия, куда разработчики приходят пообщаться, заиметь новые связи, обменяться опытом и просто отдохнуть.
Миф 6. Программирование — скучное занятие
На первый взгляд это правдоподобно: человек сидит перед монитором (или несколькими), набирает строчки кода и так целый день напролет. Ну что тут может быть интересного? Даже как-то страшно становится... Однако, это очень урезанный взгляд на то, чем занимается программист.
Прежде всего, в рассматриваемой ситуации он может:
разрабатывать одну из механик компьютерной/мобильной игры;
создавать мобильное приложение;
реализовывать привлекательный внешний вид веб-сайта;
разрабатывать программу для какого-то “умного” устройства;
работать над автоматизацией каких-то рутинных процессов, которые обыватели проделывают чуть ли не каждый день;
писать программное обеспечение для космического аппарата, самолета, машины;
и многое другое.
Поверьте, кто-кто, а программисты не скучают — для них всегда есть работа, которая требует и знаний, и навыков, и творческого подхода к решению. К тому же, у каждого человека свой спектр интересов. Кто-то программирование считает скучным вследствие своего гиперактивного способа жизни, а кто-то просто поддается влиянию когнитивного искажения, прислушиваясь к собственному ложному суждению, обусловленному субъективными предубеждениями и стереотипами, социальными, моральными и эмоциональными причинами, то есть, вырабатывает свое отношение к программированию на основе искаженной информации.
Миф 7. Программисты всё пишут с нуля
Современные сложные программы состоят из сотен тысяч строк кода. Если бы программисты писали всё с нуля, то на разработку одной такой программы уходило бы очень много времени, особенно, если говорить про игры — там и вовсе приходилось бы для каждого нового экземпляра и движок свой создавать, и физику свою писать и делать много других лишних движений. А это и время, и деньги, и лишние нервы.
Поэтому в среде программистов принято не заниматься разработкой “велосипедов”, а использовать проверенные наработки. Разработчики часто применяют сторонние библиотеки, а также код, который был написан ими самими либо другими кодерами для других проектов. Это существенно упрощает и ускоряет создание проектов любой сложности и любого объема.
Миф 8. Чтобы устроиться на работу в качестве программиста, необходимо очень долго учиться
В каждом человеке это утверждение находит различное отображение. Кто-то может освоить ЯП и необходимые технологии за месяц. Кому-то на это потребуется пол года. Некоторые и за год не управятся.
Все зависит от вашего желания и стремления изучать ЯП, а также от времени, выделяемого вами на теорию и практику. Поставьте перед собой четкую цель и не сворачивайте с выбранного пути. Максимально быстрого обучения можно достичь, выбрав хорошие курсы, разбавляя их большим количеством самостоятельной практики.
Миф 9. После курсов у вас сразу высокая ЗП
Один из самых распространенных мифов, который делает программистов в глазах других, незнакомых с данной сферой занятости людей, буквально миллионерами. Мол, “вот мой знакомый недавно листовки раздавал, потом походил на курсы 2 месяца и теперь деньги лопатой гребет”. На самом деле все не так.
Те, кто только окончил курсы по освоению той или иной IT-специальности, по своему уровню знаний и умений могут претендовать на должность разработчика-джуниора (младший разработчик, Junior Developer). Конечно, все зависит от выбранного направления и конкретного места работы, однако джуниоры не срывают куш и первое время имеют довольно невысокую зарплату, которая не всегда доходит до пятизначной отметки (если говорить об украинских гривнах). Приблизительно на третий год работы можно говорить о действительно хорошей заработной плате.
Так что запомните: высокая ЗП — даже в IT — результат не курсов, а усердной и ответственной работы.
Миф 10. “Выучи язык программирования… за 1 час!”
Миф касается различных видео уроков на YouTube, которые пестрят подобным названием и тем самым обманывают вас. Ни один язык программирования не учится за час. Большое количество опытных программистов утверждают: сколько лет они программируют, столько они изучают ЯП. Языки взаимодействия с электронно-вычислительными устройствами настолько же компактны и многогранны, как и те, которыми мы пользуемся в повседневности.
Таким образом, во время изучения ЯП вы осваиваете основной синтаксис языка и то, как с ним работать. Затем во время профессиональной деятельности вы углубляетесь в язык и открываете для себя новые техники кодинга и решения различных задач. Но даже процесс овладения языком (синтаксис + основы работы с ним) — небыстрый процесс. У опытного программиста изучение нового ЯП может занять несколько дней. У новичка могут уйти месяцы — все зависит только от вас. Но на всевозможные “Выучи язык… за 1 час!” и подобные вещи не ведитесь; такие видео ролики создают иллюзию того, что вы знаете ЯП, в то время, как на самом деле вы толком ничего и не умеете.
Миф 11. Нельзя освоить программирование самостоятельно
Можно. Просто на это уйдет больше времени, чем на обучение при помощи специализированных курсов. Причины тому очень просты:
отсутствие ментора, который бы мог направлять вас в нужное русло, давать советы и отвечать на вопросы;
отсутствие предельно четкого понимания о знаниях и умениях, которыми необходимо обладать, чтобы в будущем занять соответствующую должность;
отсутствие четкой программы обучения, которая покроет весь необходимый профильный материал;
отсутствие стимула и достаточной мотивации, которые обычно присутствуют в коллективной среде (тренер, другие учащиеся, домашние задания и т. д.).
Главная проблема самостоятельного обучения в силе воли, которая зачастую быстро испаряется и в итоге изучение ЯП сводится к нулю. А программирование вещь серьезная — на недельку-другую все забросил и вот ты уже ничего не помнишь. Так что самостоятельно обучаться программированию можно, главное — запастись упорством, терпением, силой воли и мощной мотивацией, которая должна постоянно подпитываться.
Миф 12. Программисты разбираются во всём, что связано с техникой
Как вы поняли из вступления статьи, это тоже миф, причем один из самых распространенных.
Разработчик мобильных приложений специализируется на создании программ под мобильные устройства. Он знает соответствующие ЯП и смежные технологии, которые позволяют ему выполнять свою работу качественно и без лишних затрат времени, однако, с какой стати этот специалист должен уметь чинить телевизоры и устанавливать Windows?
Или, например, человек увлекается программированием микроконтроллеров. Почему он должен уметь создавать веб-сайты, если это абсолютно другая отрасль в IT? Вы же не требуете от педиатра вылечить вам зуб, а от стоматолога — избавить вас от кашля? Хотя и тот и тот специалист — врач. Каждый является специалистом в своей области и не следует это забывать.
Сюда же относится и миф о хакерах, согласно которому программисты приравниваются к людям этого рода деятельности. Опять-таки, сторонники данной теории слишком плохо знают IT-сферу, поэтому все равняют под одну гребенку. То, что человек разбирается в определенном ЯП и смежных технологиях не делает его хакером. Хакерство — это специфический род деятельности, который предусматривает достаточно глубокие знания компьютерных сетей, операционных систем, социальной инженерии, криптографии и множества других IT-ответвлений.
Если хотите узнать больше подробностей, не пожалейте своего времени — совершите поиск по специализированным ресурсам и тогда сможете расставить все точки над “i“ — кто кем является и какой спектр знаний-умений какому IT-специалисту свойственен.
Миф 13. Программирование — мужское занятие
Безусловно, мужчин в программировании больше, чем женщин. По данным исследования Stack Overflow Developer Survey 2020, женщин среди разработчиков 8%. В Украине процент женщин в IT в 2020 году достиг уровня 25%, согласно исследованиям DOU.ua. Однако, это связано, скорее, с определенными социальными и психологическими явлениями. Дело в том, что женщины по своей природе более “социальны”, чем представители мужского пола. Соответственно, они чаще выбирают те сферы занятости, которые предусматривают общение и социум.
В то же время парни и мужчины увлечены преимущественно техническими науками, поскольку достаточно распространенная среди них интровертивность позволяет посвятить необходимое количество времени цифрам, формулам и вычислениям. Плюс детская любовь к конструкторам, машинам, компьютерным играм и всему, что связано с техникой, с экспериментами. Ну и стереотипы, привитые обществом — куда же без них.
Однако, это ни в коем случае не означает, что женщинам путь в программирование заказан. С каждым годом все больше и больше представительниц прекрасного пола покоряют IT в различных его секторах. Не ведитесь на предубеждения — программирование абсолютно открыто для всех полов, народов и возрастов.
Миф 14. Существует самый-самый лучший языка программирования
Очень часто в интернете можно наткнутся на неутихающие дискуссии касательно того, какой ЯП лучше. Однако “лучшего” не существует. ЯП подбирается под задачу, а не задачи под ЯП. Если вы хотите максимально быстро развернуть свой сайт, лучше обратить внимание на Python и фреймворк Django. Хотите самостоятельно запрограммировать, допустим, сигнализацию с инфракрасным датчиком? Выбирайте C/C++ либо низкоуровневый Assembler. Те же С/С++ подойдут под разработку тяжеловесных игр, а для более простых идеальным выбором будет среда разработки Unity вместе с языком C#. FrontEnd разработка немыслима без языков верстки HTML & CSS, а также языка программирования JavaScript. Определитесь с тем, какая сфера разработки вам интересна и тогда выбирайте тот язык, который вам по душе.
Миф 15. Разработчики компьютерных игр — самые богатые и счастливые люди в IT
Казалось бы: ты посвящаешь себя тому, о чем мечтал, наверное, каждый ребенок девяностых и нулевых — компьютерным играм. Ну что может быть прекраснее этого? Воплощаешь в жизнь все свои детские задумки: создаешь героев, работаешь над их характерами, занимаешься реализацией собственного геймплея, придумываешь уникальные квесты, сюжет не хуже “Игры престолов”, открытый и насыщенный игровой мир… Да вот только одна проблема — это так не работает; на деле все получается совсем иначе.
Чтобы стать разработчиком игр, необходимо ими “гореть”, причем “гореть” так, чтобы ни время, ни вода, ни песок, ни отсутствие кислорода не смогли потушить ваше пламя.
Во-первых, богатство гейм девелоперов преувеличено. Если игра “выстреливает”, либо вы работаете на плюс-минус солидную студию, то тогда можно говорить о деньгах. Однако, приличное количество разработчиков занимаются инди-играми, то есть, разрабатывают игры без финансирования крупных компаний (в одиночку, либо небольшими группами энтузиастов). Естественно, пока вы работаете над своим продуктом, единственным источником внешних доходов могут быть лишь пожертвования (донаты) от потенциальной аудитории, которая заинтересована в вашем творении.
Также, важно знать, что разрабатывать игры и играть в них — две абсолютно разные вещи. Игростроение — сам по себе трудоемкий и комплексный процесс, который сильно отличается от того, что мы себе воображали в детстве.
Подробнее о пути гейм-мейкеров вы можете прочесть в нашей статье “Как стать разработчиком игр”. В ней мы постарались собрать максимальное количество информации с отечественных и зарубежных информационных ресурсов, чтобы подать вам все самое вкусное в одном компактном виде.
Миф 16. Начинающим айтишникам устроится на работу невозможно
Действительно, если брать на рассмотрение популярные направления в IT, то конкуренция достаточно большая. И это на фоне растущих с каждым годом требований от работодателей. Однако, это не означает, что IT-отрасль закрыла свои двери перед новичками. Как раз таки наоборот.
Сегодня функционирует множество программ стажировок от известных компаний, занимающихся созданием программного обеспечения. Например, EPAM, GlobalLogic, SoftServe и другие открывают вакантные места для тех, кто хорошо знает предметную область, но не имеет опыта работы. Конечно, необходимо будет пройти тестирование и/или собеседование, однако, это уже упрощает процесс внедрения в рабочую среду желанной IT-секции.
Миф 17. Пойду в ВУЗ, там меня научат программированию
В ВУЗе не обучают программированию в соответствии с теми требованиями и ожиданиями, которые предъявляют к соискателям IT компании. Хоть вам и будут преподавать алгоритмы и различные ЯП, но нагрузка в вузе будет настолько объемной и пёстрой, что вы физически не сможете нормально научиться программировать. Все равно вы будете вынуждены самостоятельно учить/доучивать тот или иной язык.
Если бы вы поступали на факультет, допустим, прикладной математики, вы бы туда шли с сильными знаниями по математике, правда? Так же само и с айтишными факультетами: если вы туда идете, у вас УЖЕ должен быть опыт программирования на любом ЯП. Иначе вам будет очень тяжело и мучительно больно.
Миф 18. Программирование имеет возрастные ограничения
Языки программирования, как и любые иностранные языки, вы можете начать изучать в любом возрасте. Возрастные рамки отсутствуют. Самое главное — это ваше желание учиться, развиваться и познавать.
Как показывает практика, уже с 8-9 лет дети способны понимать основные концепции ЯП и успешно создавать собственные программы. Если говорить об относительно великовозрастных людях, с ними работает то же правило — никогда не поздно учиться и узнавать нечто новое. Более того, активная мозговая деятельность (как такая, которая происходит в процессе программирования) является отличной профилактикой многих заболеваний мозга, связанных со старением. Так что программирование и юных развивает, и взрослых прокачивает + помогает держать в тонусе свои мысли.
Однако, при трудоустройстве возрастные ограничения могут иметь место. Это зависит от политики компании, которая ищет специалиста.
Миф 19. Программист — вымирающая профессия: роботы заменят этих специалистов
Очень распространенное мнение, имеющее право на жизнь. С одной стороны, все верно:
программ становится все больше и больше, а значит, потребность в программистах должна потихоньку отпадать (ведь скоро будет нечего программировать!);
при этом активно развивается искусственный интеллект, способный перенимать определенные функции человека, включая написание кода, на себя.
Поговорим о первом тезисе. Вроде бы все логично, но есть одно НО. Рассмотренная выше мысль будет абсолютно верна в том случае, когда мы говорим об информационных технологиях, как об области, которая находится в некоем вакууме, причем вакуум этот ограничен, то есть, имеет свой “потолок”, выше которого не прыгнешь. Наш же мир не является ограниченным, по крайней мере, человечество еще не смогло определить его грани.
Да, человеческие возможности упираются в определенные физические ограничения (невозможно поднять руками или ногами самолет, самостоятельно прыгнуть на высоту 5 метров, проглотить целиком кокос и т. д.), однако в нашем мозгу пока что не было замечено четких ограничений. Более того, с его помощью мы научились обходить естественные физические преграды: придумали и реализовали специальный транспорт, который может перевозить тяжелые объекты; изобрели джамперы, джетпаки (реактивные ранцы) для совершения высоких прыжков и полетов в воздух на относительно небольшие высоты; специальные предметы для разделывания экзотических фруктов и т. п.
Пока что ученые не смогли выжать максимум из нашего мозга и разглядеть границы нашего сознания. Если сложить вместе безграничность наших мыслей и безграничность мира, можно прийти к выводу, что любая сфера нашей жизни поддается совершенствованию и всегда есть, куда дальше двигаться.
Все области нашей жизнедеятельности неразрывно связаны между собой, хотим мы того или нет. Особенно сфера IT — сейчас она находит свое отображение везде:
музыка;
киноиндустрия;
компьютерные игры;
банковская сфера;
транспортная инфраструктура;
сфера безопасности (физическая и кибербезопасность);
СМИ;
медицина;
аграрная отрасль;
все, что связано с космическими разработками;
научные исследования любых направлений;
сфера образования...
Так можно продолжать, пока не будут перечислены все отрасли человеческой деятельности.
Давайте обратимся к сухим фактам и посмотрим на то, как “умерли” некоторые профессии в результате их совершенствования:
человечество уже научилось создавать искусственные фрукты и овощи, но фермеры никуда не пропали; более того — некоторые страны имеют острую нехватку профессионалов в аграрном деле;
существуют дистанционно управляемые боевые машины, дроны и другие приспособления для ведения боевых действий, но никто не говорит о роспуске армейских подразделений; набор призывников и добровольцев продолжается и приветствуется во всех странах;
в супермаркетах появились терминалы самообслуживания, однако продавцов никто не уволил; посмотрите вакансии на данную должность — их пруд пруди;
пассажирские самолеты обустроены очень надежными и серьезными компьютерными системами, которые выполняют много работы за человека и даже имеют функцию автопилота, но никто не спешит увольнять самих пилотов; более того, в мире острая нехватка данных специалистов, а их зарплаты считаются одними из самых высоких в мире;
такая же ситуация и с поездами — сегодня не надо кидать уголь в печь и разгонять поезд (как в XIX веке), но водители поездов никуда не испарились;
беспилотные автомобили уже разъезжают по улицам некоторых городов, однако водители государственных и коммерческих предприятий тоже никуда не делись, вакансии пестрят предложениями для водителей;
множество других примеров.
Примерно та же ситуация и у программистов. Правда, сфера IT настолько многогранна, что профессии в результате развития данной области будут просто эволюционировать. Например, веб-мастер двухтысячных стал современным FullStack девелопером, а само направление сайтостроения поделилось на два лагеря — FrontEnd и BackEnd. На границе программирования и системного администрирования образовалась DevOps инженерия. IT-специальности будут попросту перерождаться и образовывать новый виток с новыми должностями.
Для осознания системности нашего мира советуем прочесть книгу “Введение в системный анализ” (Ф. И. Перегудов, Ф. П. Тарасенко). Прекрасный труд, который очень хорошо демонстрирует взаимосвязанность всего, что нас окружает. Воспитывает системное мышление и заставляет смотреть на вещи более адекватно и трезво, находить логические связи между всевозможными событиями и процессами в нашем мире.
Поговорим о втором тезисе. Он касается искусственного интеллекта (ИИ). Сюда же добавим системы генерации кода, существующие в наше время. К примеру, взглянем на сервисы, которые позволяют создавать собственные сайты без знания IT технологий.
Действительно, сегодня существуют подобные системы, использование которых исключает необходимость владения языками верстки и программирования, однако они предоставляют достаточно шаблонные решения. В них вы не сможете воплотить все свои задумки — это сможет сделать только живой специалист. Системы генерации кода хорошо справляются с типичными задачами, однако в реальных ситуациях, где не всегда всё просто и зачастую необходимо импровизировать, сохраняя при этом код “в чистоте”, они бессильны.
Возвращаясь к разработчикам сайтов: верстальщики, FrontEnd и BackEnd разработчики не исчезли и спрос на них является одним из самых высоких среди направлений в IT.
ИИ уже давно разрабатывается и ученые демонстрируют потрясающие результаты: системы, которые обыгрывают шахматных гроссмейстеров и легенд покера, робот София, системы по распознаванию образов и т. д. Однако, какого-то обвала рынка программистов не последовало, массовые увольнения специалистов замечены также не были. Все спокойно.
Посетите, например, такие ресурсы по поиску работы, как https://jobs.dou.ua/, grc.ua, hh.ru — вакансий для сайтостроителей много, равно как и для других айтишных специальностей. Не похоже на упадок эпохи программирования.
Несмотря на то, что сфера IT и без того находится на пике популярности, она испытывает дефицит рабочих кадров. Так что вы сможете прекрасно себя реализовывать в IT еще несколько десятилетий как минимум. Главное — следите за тенденциями в IT и ловите попутный ветер.
Итоги
Большинство мифов, касающихся IT, рождены обыкновенным незнанием предметной области и изрядной долей ложных предубеждений. Сегодня мы постарались разрушить некоторую часть из них и показать вам, что программирование — не башня из слоновой кости, а вполне реальная и податливая сфера человеческой деятельности, в которой кипит жизнь и которая нуждается в пополнении своих рядов.
Не бойтесь делать шаги навстречу программированию. Разрушайте стены незнаний и непониманий. Если вы в чем-то неуверенны, интересуйтесь у знакомых-программистов, пишите на форумах, спрашивайте на стримах. Все зависит только от вас!
Желаем вам всевозможных успехов и профессиональных свершений!
Оставайтесь с ITVDN!