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), Евгению Думе, Сергею Яремчуку, Вадиму Шкилю, Александру Билюку, Александру Нежинскому, Владиславу Граму, Станиславу Коленкину, Олегу Миколайченку, Антону Гаврилову.

Тип сайта и его тематика Функциональность сайта На сегодняшний день более половины всех сайтов в сети Интернет используют ту или иную систему управления контентом (Content Management System – CMS). Однако термин CMS не получил, к сожалению, четкого определения. Он может иметь несколько значений в зависимости от сценариев и целей человека или проекта. Некоммерческая международная организация AIIM (Association for Information and Image Management - Ассоциация по вопросам Управления Информацией и Изображениями) ввела в обиход понятия ECM (Enterprise Content Management) и WCM (система управления веб-контентом) как две составных части CMS.  В этом случае под ECM подразумевается программный комплекс, обеспечивающий документооборот, работу внутренней базы знаний и организующий в общем виде набор бизнес-процессов предприятия. Как одну из функций ECM может включать в себя и работу с веб контентом. Хорошим примером такого типа систем является платформа Microsoft SharePoint. В свою очередь WCM стало включать в себя набор инструментов в некотором комплексе, позволяющем управлять веб-сайтом и контентом на нем. Часто также CMS также называют «движком» сайта. В обиходе у разработчиков устоявшимся значением, подразумеваемым под CMS, является некоторая программная система, применяемая для создания, редактирования и управления контентом сайта и устанавливаемая на свой хостинг. В дальнейшем, в этой статье мы примем за основу именно это - последнее определение, более похожее на WCM. Стоит отметить и часто включаемые в число CMS так называемые SaaS решения (software as a service – услуга доступа к программному обеспечению). В случае такого типа услуг компании не предоставляют код, который вы можете скачать, установить и настроить под себя на своём хостинге. Провайдеры услуги SaaS предлагают для клиентов свои платформы, со своим хостингом, своими индивидуальными возможностями без предоставления CMS в обиходном понимании. При такой схеме вы фактически оплачиваете не владение вашим сайтом, а его аренду. В нашей статье мы не будем рассматривать такой тип услуг.   Рассмотрим подходы, которых следует придерживаться, решая вопрос как выбрать движок для сайта.   Критерии выбора CMS для вашего сайта Тип сайта и его тематика Большой выбор различных систем управления контентом на рынке объясняется различиями в типах сайтов, для которых лучше всего конкретная CMS подойдет. Будет это форум или интернет магазин, блог или корпоративный сайт, сайт-визитка или новостной портал – определенность с тематикой сайта это первое, от чего будет зависеть правильный выбор CMS. Функциональность сайта Не смотря на определенную специализацию каждой CMS под определенные задачи, на сегодняшний день для ТОП CMS существует огромное количество различных расширений (плагинов, модулей), существенно увеличивающих их функциональность и возможности «донастройки». К примеру существующими плагинами можно превратить «блоговый» движок в интернет-магазин, а на движке портала сделать форум. Однако нужно понимать, что большое количество дополнительных плагинов будут влиять и на быстродействие, и на безопасность, и на внутреннюю слаженность работы механизмов сайта, из-за возможных конфликтов этих расширений. Также определенный набор проблем может доставить и необходимость регулярных обновлений как самого движка, так и установленных плагинов. Без таких обновлений у вас будут открываться дыры в безопасности, а это вряд ли вам понравится. А обновление большого числа расширений может вызвать конфликты совместимости. Поэтому правильный выбор CMS это баланс между нужной готовой функциональностью движка «из коробки» и количеством (и качеством) установленных расширений. Исходя из задач и потребности в балансе, сложно однозначно ответить на вопрос «какая CMS лучше?». Требовательность к ресурсам Правильный выбор тематики сайта приводит к необходимости выбора условной «мощности» движка. «Мощнее», в нашем случае, вовсе не обязательно значит – «лучше». Если вы нуждаетесь, к примеру, в сайте-визитке, установка движка портала для вас будет избыточной. Значительная часть ресурсов мощной CMS останется не задействованной. При этом требования к хостингу такого сайта будут выше – вам понадобится больше оперативной памяти, больше ресурсов процессора, могут понадобиться некоторые специфические настройки сервера и предустановленное программное обеспечение. Также стоит понимать, что, к примеру, сайты администрации для поселка и для города миллионника хоть и имеют общую тематику, но будут иметь разный дизайн, функциональность, наполнение, разную посещаемость и, соответственно, разные требования. Поэтому, при выборе вам следует исходить и из масштабов вашего будущего сайта. Неправильный выбор выльется либо в необоснованное удорожание и хостинга, и администрирования вашего сайта, либо в нехватку ресурсов. Возможность кастомизации движка Многим владельцам сайтов не хватает возможностей «голой» CMS. Кроме того, из-за специфики каждого конкретно бизнеса и каждого конкретного сайта, возможности расширения с помощью дополнительных плагинов тоже может быть недостаточно. Может потребоваться индивидуальная доработка движка, тем оформления или доработка под заказчика тех плагинов, функциональности которых не вам хватает. В этом вопросе нам очень важно будет понимать следующие моменты: Количество разработчиков на рынке – специалистов по конкретной CMS; Количество и качество документации к CMS и плагинам; Развитость сообщества пользователей и разработчиков конкретной CMS. Можно с уверенностью сказать, что чем более распространён движок – тем больше доступных специалистов, тем проще внести нужные правки и тем дешевле эти правки обойдутся. Стоит уделить внимание и особенностям SEO-оптимизации конкретного движка. Если вы хотите, чтобы аудитория вашего сайта росла, вам придется соответствовать ряду правил, касающихся и скорости работы сайта на различных типах устройств, и внешнего дизайна сайта вообще и конкретных страниц в частности, и внутренней иерархии страниц, и правильной настройки индексации и т.п. Возможность проведения SEO оптимизации вашего сайта сложно переоценить.  Наличие уже встроенных в CMS SEO инструментов или доступных качественных плагинов, а также возможность доработки их под ваши нюансы проекта привлеченными разработчиками, будут очень важны на этапе продвижения вашего сайта. Стоимость CMS и доработки. На рынке сегодня присутствуют как качественные бесплатные, так и значительное количество различных платных CMS. Кроме того, выбирая бесплатные CMS, вам вероятно захочется добавить в них платные расширения.  Выбирая между платными и бесплатными вариантами вам стоит заранее определиться с несколькими моментами: Представить себе (хотя бы приблизительно) стратегию развития вашего сайта. От понимания дальнейших перспектив будет зависеть комбинация доступных расширений и необходимость их доработок. Может так сложиться, что выбор бесплатной CMS, с учетом плагинов и доработок для получения нужного функционала, окажется существенно дороже, чем купить платную CMS и платный плагин, получив при этом техническую поддержку разработчиков этой CMS. Также может оказаться, что нужный для вас плагин под конкретную CMS нужно будет разрабатывать с нуля, тогда как под другую CMS такой плагин есть уже готовый, давно выпущенный и протестированный в реальной работе.   Распространенность CMS и ее востребованность Если выбранный вами движок сайта окажется непопулярным и его разработчики решат перестать выпускать обновления, вы столкнетесь с рядом проблем. Это и падение уровня безопасности системы, и ухудшение внешней привлекательности на фоне новых сайтов-конкурентов, использующих новые технологические решения. Также существенно сложнее будет найти специалиста для внесения доработок в движок, использующий уже устаревшие и непопулярные технологии. В свою очередь выход новейшей версии движка может быть связан с кучей багов системы, наличия новых дыр безопасности, несовместимости со старыми плагинами и другими сложностями. Самописные движки Наличие такого числа сложностей при выборе системы управления для своего сайта может вызвать у вас желание заказать или написать свой сайт с нуля. Действительно, ряд проектов прямо потребует от вас такого подхода. Подключение к своим специфическим сервисам, интеграция с другими уникальными проектами, гибкость в дизайнерских и архитектурных решениях – в определенных обстоятельствах написание своего движка будет правильным решением. Однако стоит сразу учитывать набор проблем, с которыми вам предстоит столкнуться: Подсадка «на иглу» одного разработчика. Полноценно разбираться в куче кода, с слабо или вовсе недокументированными возможностями, сможет только сам автор кода. Новому разработчику может оказаться проще переписывать модули вашего сайта с нуля, чем тратить время на разбор чужого кода. Это с одной стороны существенно удорожит работу, а с другой жестко привяжет вас к конкретному разработчику. Даже сменив одного программиста на другого, вы оказываетесь в той же ситуации, только теперь с новым разработчиком. Сроки и цена разработки. Написание нужных модулей «с нуля» будет стоить значительно дороже и займет значительно больше времени, чем адаптация уже существующего движка и плагинов с хорошей документацией от авторов. Проблемы тестирования и ошибок. В движках, которые используют каждый день миллионы человек, есть значительный плюс – большинство багов выявляются мгновенно и быстро перекрываются обновлениями. Наличие багов в вашей самописной системе будет зависеть как от навыков вашего разработчика, так и от применяемых им технологий. Эта комбинация может нести большое количество скрытых проблем как работоспособности, так и безопасности, которые останутся не выловленными, пока не станет слишком поздно. В результате разработка своего движка оказывается выгодна, практически, только крупным компаниям со своими внутренними отделами разработки и тестирования, которые будут писать свой сайт и поддерживать его работоспособность независимо от сторонних разработчиков. Статистика использования CMS   По данным сайта w3techs.com более 55% всех Web-сайтов в Интернете управляются теми или иными CMS. Как видно из диаграммы более 33% всех сайтов в Интернете работают на движке WordPress. Фактически это более 60% от сайтов, управляемых теми или иными CMS. Следующие по популярности системы CMS: Joomla – 5.4%, Drupal – 3.5%, Magento – 1.8%, PrestaShop – 1.4%. Набравшие в этой диаграмме высокие места Shopify (2.7%), Squarespace (2.7%) и Wix (1.8%) предлагают услуги SaaS (которые мы здесь не рассматриваем). По данным портала WhatСms первое место по числу сайтов среди популярных CMS также принадлежит WordPress - 52.74%. Затем идут Joomla - 5.219%, Drupal - 3.953%, Magento - 2.840%, PrestaShop - 1.671%. Blogger, как и несколько компаний в предыдущей диаграмме, является SaaS платформой. По данным портала BuiltWith первые три места среди не SaaS CMS занимают: WordPress - 28.27%, Joomla – 26.93%, Drupal – 8.84%. По данным портала SimilarTech, предлагающего свой ТОП движков для сайтов, среди 9,5 млн сайтов на CMS также лидирует WordPress, заняв 68% рынка CMS. Слетом идет Drupal (версии 6 и ниже) – 4%, Joomla – 3%, Drupal 7 – 1%, Typo3 – 1%. В число других CMS вошли как SaaS решения, так и другие полноценные CMS, включая и Drupal 8. Проанализировав указанную статистику, мы выбрали следующий 6 ТОП CMS: WordPress, Joomla, Drupal, Magento, PrestaShop и Typo3. Проведем краткий обзор движков для сайтов, входящих в наш ТОП CMS.   1) WordPress Выпущенный впервые в 2003 году, CMS WordPress быстро завоевал популярность как у продвинутых разработчиков, так и простых пользователей. Благодаря простой настройке, не самой высокой требовательностью к ресурсам хостинга и огромному количеству расширений эта CMS уже многие годы занимает первое место. На сегодня именно WordPress называют лучшей CMS для блога. WordPress идеально подходит для довольно простых веб-сайтов, таких как ежедневные блоги и новостные сайты, и для тех, кто ищет для себя простую CMS. Дополнения позволяют легко расширять функциональность сайта. К примеру, благодаря плагину WooCommerce, из сайтов на движке WordPress получается удобный для управления интернет-магазин – один из самых распространенных вариантов интернет-магазинов в сети. Нужно отметить и большое количество SaaS решений, использующих на своей платформе этот движок. Часть успеха WordPress в представленных диаграммах без сомнения относится к SaaS решениям. Официальный сайт WordPress: https://wordpress.org/ Особенности WordPress: Последняя версия - 5.0.3 от 09.01.2019. Написан на PHP. Более старые версии чем 5.0 официально объявлены «небезопасными». Минимальные требования к хостингу, поддержку которых обещает разработчик: PHP 7.3 MySQL 5.6 или MariaDB 10.0; HTTPS; Apache или Nginx. Плюсы WordPress: Бесплатная CMS распространяется с открытым исходным кодом. Огромное количество как платных, так и бесплатных шаблонов, и плагинов. Удобная панель администратора. Простая CMS для пользователя. Отмечают простоту использования и легкость установки как движка, так и тем, и расширений. Большое сообщество. Достаточно высокая производительность. Доступные платные плагины с проверенным качеством. Минусы WordPress: Относительно не маленькая требовательность к ресурсам, особенно при установке значительного числа плагинов. Отсутствие технической поддержки в не SaaS вариантах. Многие плагины написаны некачественно, что создает проблемы в работе и дыры в безопасности. Сайты на WordPress взламывают чаще всего.   Для каких сайтов используют CMS WordPress: Популярность WordPress продолжает расти: При этом в Украине сейчас 34910 сайтов используют эту CMS, а в Российской Федерации - 297353.   2) Joomla CMS Joomla впервые увидела свет в 2005 году. Отражая философию этого движка, его назвали словом, звучащим на суахили как «всё вместе». Фактически разрабатываемая как CMS для порталов, Joomla позволяет создавать сайты с большей гибкостью контента и внутренней структуры, чем WordPress, но при этом с достаточно простым и интуитивно понятным интерфейсом. Эта CMS поддерживает электронную коммерцию, социальные сети и многое другое. Используя этот движок, разработчики создают сайты-визитки, интернет-магазины, фотогалереи, порталы (включая новостные), блоги и другие сайты. Рядом пользователей, Joomla признается лучшей CMS для сайта типа портал. Официальный сайт: https://www.joomla.org/ Особенности движка Joomla: Последняя версия – 3.9.3 от 12.02.2019. Написана на PHP и JavaScript. Минимальные системные требования: PHP 5.3.10; MySQL  5.1 или SQL Server 10.50.1600.1 или PostgreSQL 8.3.18; Apache 2.0 или Nginx 1.0 или Microsoft IIS 7. Плюсы Joomla: Бесплатное распространение с открытым исходным кодом по лицензии GNU GPL v2, включая обновления; Частое предоставление обновлений движка; Большое сообщество пользователей и разработчиков; Большое количество доступных платных и бесплатных тем и плагинов; Относительно не высокий уровень требований к разработчику и пользователю. Минусы Joomla: Отсутствие технической поддержки. Вторая CMS по числу взломов. Joomla применяется в следующих сферах: В Украине 907  сайтов используют эту CMS и 3800 сайтов - в Российской Федерации. Есть определенная тенденция по снижению популярности CMS Joomla: 3) Drupal Впервые вышедшая в 2000 году, CMS Drupal является мощным, удобным для разработчиков инструментом для создания сложных сайтов. Как и большинство мощных инструментов, Drupal требует определенных знаний и опыта для работы. На основе Drupal часто создают порталы, новостные сайты, форумы, интернет-магазины - одни из самых продвинутых сайтов. Тем не менее Drupal является самым сложным для пользователя движков из тройки лидеров. Хотя его использование с каждым выпуском и становится все проще, если вы не готовы погрузиться в изучение этого программного обеспечения или не можете нанять кого-то, кто его знает, возможно, это не лучшая система управления контентом для вас. Официальный сайт: https://www.drupal.org/   Особенности Drupal CMS: Последняя версия 8.6.10; Ядро предоставляет только минимальный функционал, нужный для работы CMS, остальной функционал добавляется за счет плагинов. Установка модулей происходит в связке. Если для реализации функционала какого-то модуля нужны другие модули – они установятся автоматически в связке с первым модулем. Минимальные требования к хостингу для CMS Drupal 8: PHP 5.x/7.x для x86 и PHP 5.x для x64; MySQL 5.5.3 или MariaDB 5.5.20, или Percona Server 5.5.8, или PostgreSQL 9.1.2, или SQLite 3.6.8; Microsoft SQL Server и MongoDB поддерживаются благодаря отдельным модулям; Apache 2.x (используется в качестве Web-сервера для Drupal чаще всего) или Nginx (0.7.x, 0.8.x, 1.0.x, 1.2.x), стабильная версия 1.8.x или 1.9.x. Плюсы Drupal: Бесплатная CMS с открытым исходным кодом GNU GPL 2+. Стабильная работа ядра движка. Большое количество бесплатных тем, и различных расширений. Достаточно развитое сообщество разработчиков. Для решения типовых задач есть готовые наборы плагинов. Drupal известен своей мощной таксономией и способностью отмечать, классифицировать и организовывать сложный контент. Минусы Drupal: Сложность использования для начинающих пользователей. Меньшее количество доступных бесплатных плагинов чем у предыдущих CMS. Отмечают большую требовательность к хостингу за счет более частых обращений движка к базе данных, чем у других движков. Сегодня эту CMS используют в 7110 сайтов в Украине и 45189 сайтов в Российской Федерации. Можно наблюдать определенное снижение интереса к этой CMS по сравнению с 2016 годом:   4) Magento CMS Magento — движок для интернет-магазинов и других вариантов электронной коммерции. В основном популярен в западных странах и слабо представлен в русскоязычной части Интернета из-за слабой интеграции с местными сервисами. В настоящий момент является собственностью Adobe Inc. В основном Magento используется для крупных проектов. Считается не рентабельным использовать его для магазинов с несколькими сотнями позиций в обороте из-за относительно высокой стоимости разработки. Официальный сайт: https://magento.com/. Особенности CMS Magento: Написан на PHP. Последняя версия 2.3.0 от 28.11.2018. Требования к хостингу: LAMP (Linux, Apache, MySQL, and PHP) или LNMP; Apache 2.x или Nginx 1.7.x; PHP 5.6 или 5.5 или 5.4; MySQL 5.6 (Oracle or Percona); HTTPS; Доступ к crontab и к записи в .htaccess. Плюсы Magento: Бесплатная система с открытым исходным кодом. Движок оптимизирован под требования поисковых систем «из коробки». Готовая функциональность движка в базовой версии. Являясь собственностью Adobe Inc., отлично поддерживает интеграцию с сервисами Adobe. Минусы Magento: Несмотря на открытый исходный код, многими разработчиками считается не удобным работать с этой CMS из-за особенности организации ее кода. В бесплатной версии нет технической поддержки, платная версия будет стоить несколько тысяч долларов в год. Отсутствует интеграция с платежными средствами и другими локальными сервисами на постсоветском пространстве. Низкая скорость загрузки страниц сайта «из коробки». Большая часть настроек сайта потребует специфических знаний и навыков.   В Украине на сегодня 1113 сайтов используют CMS Magento и 1774 используют ее в Российской Федерации. После 2016 года можно наблюдать некоторое снижение числа сайтов на этой CMS:    5) PrestaShop PrestaShop – это еще один пример простой CMS с открытым исходным кодом для создания интернет-магазина. Созданный в 2008 году, этот движок достаточно быстро обрел популярность и продолжает ее наращивать. Это достаточно простая бесплатная CMS создана для организации торговых площадок и интернет магазинов. Официальный сайт: https://www.prestashop.com Особенности PrestaShop: Текущая версия – 1.7.5.1 от 18.02.2019. Написан на PHP с применением фреймворка Symfony. Минимальные требования к хостингу: PHP 5.6; MySQL 5.0; Server RAM – чем больше, тем лучше; Unix, Linux или Windows; Apache 2.2 или Nginx 1.0 или Microsoft’s IIS Web server 6.0. Плюсы PrestaShop: Бесплатный движок с открытым исходным кодом. Большое количество доступных тем оформления и расширений. Достаточный для начала работы интернет-магазина стандартный набор базовой версии движка. Имеет отличную русскую локализацию. Богатый выбор модулей для развития интернет-магазина. Хорошая интеграция с различными сервисами на постсоветском пространстве. Простота установки и работы. Удобная интуитивно понятная панель администрирования. Базовая версия имеет хорошую SEO-оптимизацию. Активные сообщества разработчиков. Минусы PrestaShop: Качественные темы и расширения являются платными. Более требователен к ресурсам чем WordPress. Низкая безопасность у бесплатных тем и плагинов. Наблюдаются баги при проведении внутренней оптимизации. Можно видеть рост популярности CMS PrestaShop. Например, на сегодня уже 2461 сайт работает на этом движке в Украине, и 8423 сайтов - в Российской Федерации.    6) Typo3 Typo3 это CMS с открытым исходным кодом. Впервые этот относительно универсальный движок был представлен в 1998 году. Typo3 часто применяется для новостных порталов, интернет-магазинов, корпоративных сайтов и других вариантов сайтов.   Официальный сайт: https://typo3.org/.   Особенности Typo3: Написан на PHP. Последняя версия 9.5.4 от 22.01.2019. Особенностью Typo3 является то, что в проектах на этой CMS вся информация публикуется от администратора и сайты не работают с пользовательским контентом. Typo3 не приспособлена для создания блога, активно взаимодействующего с пользователем портала или социальной сети. Минимальные требования к хостингу: Linux, Windows или Mac; PHP> = 7.2; PostgreSQL / Microsoft SQL Server / MariaDB >= 10.2 / MySQL >= 5 <= 5.7 / SQLite; Apache httpd или Nginx или Microsoft IIS, Caddy Server. Плюсы Typo3: Простота администрирования сайта. Возможность управления несколькими проектами из одной панели администратора. Возможность создания отдельных разделов на сайте с раздельным доступом для разных типов пользователей. Минусы Typo3: Относительно высокая требовательность движка к ресурсам сервера. Сложность изучения документации. Основная часть материалов не переведена с английского. Также, как и у ряда предыдущих CMS, у Typo3 наблюдается снижение популярности с 2016 года. В свою очередь в Украине на этом движке зарегистрировано 399 сайтов, в Российской Федерации - 1327. Полезным будет рассмотреть и сравнение производительности среди ТОП CMS.   Популярные CMS. Сравнение производительности. Согласно опубликованным данным тестирования ряда CMS, можно сделать вывод о наиболее быстром движке (пусть и в искусственных  - «тепличных» условиях теста). Указанные данные в таблице – это количество обрабатываемых запросов в секунду. Наиболее быстрой в данном исследовании среди популярных CMS показала себя WordPress 5.0 с версией PHP 7.3.   Вывод В нашем кратком обзоре CMS мы рассмотрели ТОП 6 наиболее распространенных CMS в мире. Как мы видим, каждая из них имеет свою специфику и особенности. Из-за разных возможных сфер применения сложно выбрать лучшую систему управления сайтом. Как лучшая CMS для блогов многими пользователями отмечается WordPress, а PrestaShop многими определяется как лучшая CMS для сайта интернет-магазина. Стоит понимать, что большая часть представленных в нашем ТОП CMS движков являются относительно универсальными. Кроме PrestaShop и Magento, ориентированных на интернет-коммерцию, с помощью других движков можно делать разнотипные проекты. Однако многими разработчиками признается, что никакая универсальная CMS не будет работать в конкретной сфере также хорошо, как специально разработанная для этой цели CMS. Поэтому, полезно кроме данного обзора ТОП CMS, рассмотреть отдельно ТОП CMS для блогов, ТОП CMS для интернет-магазинов, ТОП CMS для форумов, и далее. Такие обзоры помогут лучше понять, как правильно выбрать движок для сайта с вашими уникальными потребностями. Как вы могли заметить, рассмотренные CMS из ТОП движков для сайтов написаны на PHP. Если вы определились с CMS для своего проекта и хотите его сами доработать, или просто хотите научиться работать с топовыми проектами сети Интернет - вам, вероятно, будет интересен наш набор курсов  и вебинаров на портале ITVDN: WordPress Starter и WordPress Essential WordPress: создаем блог за час Интеграция верстки лендинга на CMS WordPress PHP Starter How To PHP Starter PHP Essential 

В этой статье вы найдёте несколько полезных советов для тех, кто хочет стать программистом. Совет 1. Определитесь с языком программирования Выбор языка программирования — первая трудность, с которой встречаются новички. Сколько программистов — столько и мнений о языках, поэтому выделить «лучший» среди них нельзя. Почему? Каждый язык создан для определённой области разработки и решения определённых задач. Для выбора языка программирования, ориентируйтесь на ваши желания. Какие программы и сервисы вы хотите создавать? Делать игры на Unity? Сайты на HTML, CSS и JavaScript? Или, может быть, бизнес-приложения на С# или Java? Python широко используется в науке для быстрых вычислений. При выборе учитывайте порог вхождения языка (Python, например, изучается быстрее и легче С++) и ваши предрасположенности. Кроме того, перед изучением любого языка стоит изучить основы программирования. Разберитесь, что такое двоичный код, компилятор, познакомьтесь с алгоритмами и шаблонами проектирования. Совет 2. Применяйте метод дробления материала Если вы решили стать программистом, вам нужно будет очень мнрогое изучить и запомнить. Сделать это «с наскока» будет трудно. Не хваатайтесь за все сразу. Ставьте перед собой небольшие реальные, достижимые цели. Например, изучайте одну тему за 1 день. При изучении любого языка начинайте с самых основ, постепенно продвигаясь вперёд. Закрепляйте пройденный материал практикой, если есть какие-то небольшие пробелы в знаниях — двигайтесь дальше, возможно, вы заполните их потом. Но не оставляйте слишком много «белых пятен», иначе запутаетесь. На помощь в структурировании информации вам придут различные техники запоминания (ассоциации, карточки) и ваш собственный дневник обучения, в котором вы можете записывать усвоенный материал, как говорят, «своими словами», и затем проверять его на практике. Совет 3.  Не стесняйтесь использовать детские обучающие программы и курсы. В детских программах часто подают упрощенные знания, основы основ. Не стесняйтесь пробовать детские игры и курсы, в которых материал усваивается значительно легче. Кроме того, это бываает весело! Прослушав материал в упрощенном виде, вы сможете понять его, и дальнейшее изучение программирования будет даваться вам значительно легче. Кроме того, к временной помощи детских курсов можно прибегнуть, если какой-то участок материала даётся вам с трудом, и понять его вы никак не можете. Прослушав упрощенный материал, вы получите взгляд со стороны и, возможно, наконец сможете понять материал. Совет 4. Разбирайте чужой код Это больше относится к практике. Разбирая чужой код, вы начнёте понимать, почему программа работает или не работает. Перенимая чужой опыт, вы получаете новые знания и фишки, которые помогут вам в будущем. Читая код другого программиста, вы улучшите своё общее понимание программирования и убережете себя от ошибок. Кроме того, разбор чужого кода также может помочь вам сдвинуться с мёртвой точки. Если вам что-то не понятно, то вы можете просмотреть чей-то код и получить его советы. Таким образом, вы сможете понять, как сделать правильно и почему часть программы у другого человека работает правильно, а у вас — нет. Совет 5. Читайте полезную литературу Не смотря на то, что сейчас больше людей предпочитают литературе курсы, статьи и видео, чтение актуальных книг по программированию поможет вам глубже изучить программирование. Некоторые книги вообще являются признанной классикой, например книга Роберта Мартина «Чистый Код» детально описывает процесс создания чистого кода, и указывает на ошибки, которые могут возникнуть при написании красивого кода. Фактически, эта книга — «библия» для тех, кто стремится писать чистый код. Поискав в Гугле другие книги по вашему направлению, вы можете скомбинировать их со справочниками, и получить «универсальный набор» программиста, в котором вы найдёте ответы на большинство своих вопросов. Общепризнанную литературу можно читать в переводе, но большинство актуальной литературы выходит в мир на английском, и переводится на русский с опозданием в год-два, когда уже всё поменялось. Поэтому дополнительный совет: уделите внимание изучению английского языка! С английским вы всегда сможете получать актуальную информацию, общаться с зарубежными программистами, английский облегчит вам изучение программирования в несколько раз, и, возможно, в будущем вы найдете работу в зарубежной компании. Совет 6. Запишитесь на курсы Для некоторых людей самостоятельное изучение программирование может даваться с трудом, ведь рядом нет никого, кто мог бы в любой момент ответить на их вопросы. Многим не понятно, с чего начинать обучение и как структурировать информацию.С наставником и одногруппниками вы будете продвигаться в обучении быстрее. Если вы хотите начать изучать программирование, вам будет интересно посмотреть записи вебинаров ITVDN из серии «С чего начать?», и «Как стать программистом?» . Ваши вопросы вы можете задать, обратившись в службу поддержки ITVDN. Консультанты нашего образовательного ресурса будут рады помочь вам.

Взято с настоящего поля битвы: работы Спустя практически 10 лет работы на Javascript мне захотелось поделиться своими ежедневными секретами написания кода. Многие советы были позаимствованы у моих коллег, из книг или видео. Такие приёмы не должны оставаться в тайне, поэтому я ими и хочу поделиться!   1. Меньше кода = меньше багов Это может прозвучать тривиально, но всегда держите это в уме. Любую часть можно убрать, даже не сомневайтесь! Просто удалите. Неработающий код, неиспользуемые переменные, лишние скобки: каждый малейший знак учитывается. 2. Развивайте читабельность кода Это дополнение к пункту 1. Если хочется сократить код, всегда нужно помнить о том, что рано или поздно код будет прочитан другими людьми. Может, кто-то другой, может, через несколько месяцев, но будет очень неприятно, если придется потратить больше времени на разбор кода, чем было потрачено на его написание. Запомните: код всегда важнее, чем комментарии или документация. Следите за переменными и именами функций, они должны быть достаточно наглядными, чтобы потом не объяснять их в комментариях. 3. Не пугайтесь функций, возвращающих функции Когда я начал кодить на javascript, мне не нравился метод написания кода с использованием функций, возвращающих функции, потому что, казалось, этому сложно следовать в процессе выполнения. Но этот шаблон, довольно мощный и часто используемый, называется замыканием. Это действительно полезная функция и, как только вы используете её, она значительно облегчает структуру кода. И это первый шаг для погружения в функциональное программирование. 4. Извлекание частей Функция становится слишком большой? Сделайте из нескольких частей отдельные функции! Не совсем понятно? Выделите их в переменную и дайте ей понятное имя. Такой метод, конечно, схож со вторым пунктом, но это сделает ваш код более читабельным. А знаете ли Вы, что Ваша среда разработки может помочь? Ctrl + alt + v выражение извлекается в Webstorm и потом выделяется в переменную. Ctrl + alt + m сделает из него функцию. 5. Переверните мышление Это первый шаг перед TDD. Скорее всего, вы всегда знаете, чего хотите достичь. Так начните с конца, напишите ожидаемый результат и пишите код в обратном порядке, чтобы получить то, что хотите. Если будете писать в прямом порядке, вероятней всего, Вы начнете писать и проверять, работает ли оно. Поменяйте, проверьте, напишите что-то другое, проверьте и…. Возможно, это даже не особо полезно для достижения Вашей цели. Но такое мышление поможет сфокусироваться и потратить меньше времени. 6. Исключите условные операторы Если для функции у вас на уме принцип единственной ответственности, условным операторам тут не место. Они создают ветвления в потоке выполнения. И один маленький if позволит другим разработчикам добавить всё больше логики в него. Я считаю, что условные операторы if вообще не должны использоваться без else, а их размещение внутри другого условного оператора нужно полностью запретить! Опять же, такой подход делает код более сложным, и часто оказывается, что функция выполняет больше, чем нужно. Как же от этого избавиться? Смотрите следующий пункт. 7. Используйте lodash_.get вместо проверки null/undefined Очень часто, анализируя код, я вижу использование ifs для проверки null или undefined значений. Но без использования else! То есть идёт работа только с одним путём, а другой путь остаётся местом загадок (и багов!). Тут на помощь приходит Lodash (лучшее, написанное когда-либо на javascript) с его замечательной функцией get. Её первым аргументом является объект, над которым вы работаете, вторым – путь к дочерним атрибутам, которые вы хотите получить, и третьим является значение по умолчанию в случае с undefined. Два преимущества использования всего одной функции! 8. Используйте тернарные операторы Кто-то может поспорить насчёт их читабельности, но если правильно извлекать функции, они станут превосходным инструментом. Они также заставят Вас сотрудничать с else case. Плюс, они не позволяют содержать в себе больше кода. Чем меньше ваш код похож на смертельную пирамиду, тем лучше. 9. Никаких больше for loops, только map, reduce и filter Мы, наконец-то, подошли тут к теме функционального программирования, так как эти методы являются основой этого стиля. Хоть названия или теории не особо известны, они действительно помогут избежать тяжело читаемого императивного стиля для выражений for. Эти методы сейчас уже встроены в большинство браузеров, так что используйте их! Но если вам всё же нужна совместимость, можно использовать lodash аналоги. Итак, когда их использовать? Выражение for, имеющее дело со всеми точками входа – это map for + if , вероятно, filter sum или accumulation -  это просто reduce  С помощью сочетания этих методов вы можете сделать много работы в хорошей и краткой форме. 10. Читайте исходники Если документации недостаточно - читайте исходники! Это поможет Вам узнать, как их использовать и даст неплохое представление об их качестве. Плюс, некоторые библиотеки имеют исходники, встроенные в их документацию. Так с ними даже быстрее можно ознакомиться. С нашей IDE можно часто обращаться к источнику с помощью ctrl + clic на имя метода. Это отличный способ убрать магию и набраться вдохновения для собственного кода!   В заключение хотелось бы сказать, что это те принципы, которые помогают лично мне. Жаль, что я не знал их раньше, например, в школе… Зато ты знаешь их сейчас. И ими можно пользоваться практически в любом контексте. Некоторые из них распространяются не только на javascript, так что пользуйтесь ими где угодно :) Также хотелось бы обратить ваше внимание на великого Uncle Bob и его сайт . Вам определённо стоит посмотреть эти видео, даже несмотря на то, что они по большей части касаются Java, идеи применимы и в Javascript. Переведено с источника.

Введение Валидация достаточно часто вызывает затруднения с работой в веб-приложениях. Во многих случаях фреймворки должны быть использованы для валидации значений формы. Кроме того, эти фреймворки часто не работают во всех браузерах. AngularJS приходит с проверкой, построенной так, что теперь гораздо легче создать валидацию, которая работает во всех браузерах. На практике Использование angular-message Чтобы использовать angular-message, нужно внести в ваш проект модуль:  angular.module("realestateApp", ["ngMessages"]); Теперь ng-message будет доступен для использования. Формы Для инициализации процесса валидации, Вы должны начать с формы контейнера: <form name="tenantForm"> Теперь внутри тега можно добавить управление и логику на их проверку. В сценариях валидации, как правило, есть несколько основных атрибутов. Те, которые стоит использовать: Required, Minimum, Maximum, Pattern, Email, Number, и URL. Required Этот атрибут заставляет form быть недействительным, если обязательное поле не вводится. <input type="text" required /> Minimum Length Этот атрибут указывает минимум символов для ввода до того, как значение будет принято. <input type="text" ng-minlength=5 /> Maximum Length Этот атрибут указывает максимальную длину или проверка будет неверна. <input type="text" ng-maxlength=20 /> Pattern Matching Эта функция позволяет согласовать совпадения при использовании Regex. <input type="text" ng-pattern="[a-zA-Z]" /> Email Matching Angular обеспечивает пользовательские функции по электронной почте. <input type="email" name="email" ng-model="user.email" /> Number Этот требует ввода в цифровом формате перед проверкой. <input type="number" name="age" ng-model="user.age" /> URL Этот требует ввода в ссылочном формате перед проверкой. <input type="url" name="homepage" ng-model="user.url" /> Сообщение об ошибке Ранее использовался error-container, но теперь можно использовать директиву ng-message: <div ng-messages="tenantForm.Email.$error" ng-messages-include="messages.html" class="errors"></div> Также нужен файл messages.html для хранения сообщений об ошибках: <div class="messages"> <div ng-message="required">Required</div> <div ng-message="minlength">Too short</div> <div ng-message="maxlength">Too long</div> <div ng-message="email">Invalid email address</div> <div ng-message="compareTo">Must match the previous entry</div> <div ng-message="number">Must be a number</div> <div ng-message="url">Must be in URL format</div> </div> Сообщение об отмене ошибки Иногда Вы должны иметь пользовательские сообщения об ошибках, не охватываемых messages.html. Вы можете сделать это, добавив тег span в диапазон для любого сообщения об ошибке. То, что должно отобразиться: <div ng-messages="tenantForm.FirstName.$error" ng-messages-include="messages.html" class="errors"> <span class="messages" ng-message="minlength">Must be more than 3 characters</span> <span class="messages" ng-message="maxlength">Must be more than 20 characters</span> </div> Собираем всё вместе Теперь, объединив messages.html с index.html. <form name="tenantForm" novalidate style="width: 500px">     <div class="row">         <div ng-repeat="tenant in tenant">             <div class="form-group">                 <label>First Name: label>                 <input type="text"                        placeholder="First Name"                        name="FirstName"                        ng-model="tenant.FirstName"                        ng-minlength=3                        ng-maxlength=20 required />                 <div ng-messages="tenantForm.FirstName.$error"                      ng-messages-include="messages.html" class="errors">                     <span class="messages"                     ng-message="minlength">Must be more than 3 charactersspan>                     <span class="messages"                     ng-message="maxlength">Must be more than 20 charactersspan>                 div>             div>             <div class="form-group">                 <label>Home Phone: label>                 <input type="number"                        placeholder="Phone Number"                        name="HomePhone"                        ng-model="tenant.HomePhone"                        ng-minlength=7                        ng-maxlength=10 required />                 <div ng-messages="tenantForm.HomePhone.$error"                      ng-messages-include="messages.html" class="errors">                     <span class="messages"                     ng-message="minlength">Must be more than 7 digitsspan>                     <span class="messages"                     ng-message="maxlength">Must be less than 11 digitsspan>                  div>             div>             <div class="form-group">                 <label>Email: label>                 <input type="email"                        placeholder="Email"                        name="Email"                        ng-model="tenant.Email"                        required />                 <div ng-messages="tenantForm.Email.$error"                      ng-messages-include="messages.html" class="errors">div>             div>             <div class="form-group">                 <label>Webpage: label>                 <input type="url"                        placeholder="Webpage"                        name="Webpage"                        ng-model="tenant.Webpage"                        required />                 <div ng-messages="tenantForm.Webpage.$error"                      ng-messages-include="messages.html" class="errors">                 div>             div>         div>     div>               form> Этот подход кажется чище, чем использование директивы ng-show. Кроме того, это уменьшит дублирование кода путем центрального места хранения ваших сообщений об ошибках, но в то же время используется для пользовательских сообщений. Источник: http://www.codeproject.com/Articles/992545/AngularJS-Validation

Введение Как веб-разработчик, Вы можете знать, что форматирование данных на серверном языке – не очень сложная задача. Достаточно базового понимания языка и того, что Вам нужно для реализации, и вот – у Вас есть хорошо отформатированный объект даты и времени. Например, следующий код С# является хорошо отформатированным и может предоставить нужный Вам объект даты и времени. var dateOfBirth = new DateTime(1995, 08, 29); // My date of birth  var formatted = dateOfBirth.ToString("MMMM dd, yyyy"); // Would hold: August 29, 1995   В выше написанном коде мы предусмотрели формат данных, который нам нужен, и код, что обеспечит ожидаемый результат. Впрочем, делать это в JavaScript весьма трудно, потому как в JavaScript нет переопределенного метода ToString, который может преобразовать объект даты и времени в должным образом форматированное значение. Тем не менее, объекты Date в JavaScript используют методы, с помощью которых можно извлечь значения месяца, дня или года. Мы будем их использовать, чтобы сгенерировать форматированный string для объекта date. Также заметим, что в JavaScript объект даты и времени является числом, которое отображается как количество миллисекунд от 1-го января 1970 г. Поэтому, чтобы не писать свой собственный код для подсчета месяцев и дат, можете использовать встроенные функции getMonth, getDate и др. чтобы получить нужные значения. В нашей статье мы покажем Вам, как написать код и как правильно форматировать запись string в объект даты и времени. Объект даты и времени в Javascript Объект даты и времени (Date) в JavaScript намного компактнее, чем в других языках программирования. Он не обеспечивает множество функций и особенностей. Это просто конструктор, который принимает число миллисекунд или значение строки, что представляет объект даты и времени в пределах от 1 января 1970 года до сегодняшнего дня (каким бы он ни был). Вы легко можете создать его экземпляр, используя следующий код var date = Date.now(); // current date time  // OR  var date = new Date(); // new instance; default  // OR  var date = new Date('string-notation-of-datetime'); // Any date time upto 1 January 1970 from Now.   Теперь давайте поработаем с данным исходным кодом и посмотрим, что JavaScript может нам предложить. Написание веб-приложения В Вашем HTML Вы можете определить поля ввода от пользователя и установить диапазон их типов, что позволило бы пользователю вводить значение любого из этих типов. В нашей статье мы будем использовать тип date. Используем следующую HTML-разметку Примечание: мы использовали Bootstrap в качестве стиля. <input type="date" class="form-control"/> Контроль после рендеринга Это то, что у нас есть для макета, а теперь давайте обратимся ко входным данным пользователей. Мы должны найти указанную пользователем строку даты и времени, а также рассчитать по ней возраст. var dateValue = new Date($('input').val()); // Get the value    // Now comes the stringification... Following code does that.  var date = getMonth(dateValue.getMonth()) + " " + dateValue.getDate() + ", " + dateValue.getFullYear(); В JavaScript методы getDate, getMonth возвращают номер объекта. Вместо использования номера в качестве даты создадим другую функцию, которая возвращает месяц из нашего целого значения. Примечание: date.getMonth() при возврате значения начинает отсчет от 0. function getMonth(index) { // Pass the index as parameter      switch (index) { // Switch on index          case 0:             return "January";             break;         case 1:             return "February";             break;         case 2:             return "March";             break;         case 3:             return "April";             break;         case 4:             return "May";             break;         case 5:             return "June";             break;         case 6:             return "July";             break;         case 7:             return "August";             break;         case 8:             return "September";             break;         case 9:             return "October";             break;         case 10:             return "November";             break;         case 11:             return "December";             break;         default: // Wouldn't get called usually because range is 0-11              "Invalid number: " + index;             break;     } } Описанная выше функция возвращает строку для месяца. Поэтому, вышеуказанный код сможет вернуть данные в строковом представлении.Что касается функции расчета возраста, то реализовать ее не так просто, как в С# или других языках. Вам надо вручную отбросить значения объекта даты и времени в миллисекундах с 1970 года, учитывая вычисление результата от даты рождения до текущего времени. Запутались? Давайте проверим наш код и упростим формулировку. var age = Math.abs(              new Date(                    Date.now() - dateValue // 1. Get the difference as new Date object                ).getUTCFullYear() - 1970 // 2. Calculate the years           ); // 3. Get the value   Мы разделили процесс на три этапа: Прежде всего получим значение после отрицания даты рождения от текущей даты. Это будет основой для нашего алгоритма возраста. Дальше найдем UTC-значение года от значения, что мы получили через отрицание, и вычтем от него 1970. Теперь получим абсолютное значение от шага 2. Теперь функция будет вмещать значение возраста для введенных пользователем данных. Запустим вышеуказанную функцию и получим HTML, для примера HTML-разметка с указанием даты в отформатированной строке и возраста пользователя. Заключение Теперь Вы знаете как можно выбрать введенные пользователем данные и рассчитать возраст пользователя с помощью JavaScript, а также как показать его в строковом представлении для удобства чтения. Источник: http://www.c-sharpcorner.com/UploadFile/201fc1/calculating-and-formatting-date-in-javascript/

Введение Метрика программного обеспечения (англ. Software metric) – это некая мера определенного свойства программного обеспечения или же его спецификаций. Как известно, мера – это средство измерения. Важно понять, что мера - это числовое значение. Таким образом, метрика программного обеспечения будет показывать некое числовое значение определенного свойства ПО.  Мы не будем углубляться в теорию, так как ее можно найти в свободном доступе довольно легко. Мы займемся практической частью данного вопроса. А именно: как нам использовать метрики для улучшения кода? Метрики в Visual Studio Стоит заметить сразу, что метрики подвергаются критике. Это, как минимум, поверхностно и неточно. Мы вернемся к этому после того, как поймем о чем речь. Рассматривать мы будет все на примере Visual Studio 2015 RC. Сперва, откроем проект для изучения. Далее, мы можем видеть вкладку Analyze В этой вкладке мы видим Calculate Code Metrics for ... Это нам и нужно. Разница лишь в том, что будет анализироваться. Или же выбранные проекты в Solution Explorer, или же сразу весь Solution. После нажатия придется немного подождать. Время зависит от конфигурации Вашего компьютера. Когда анализ будет завершен, Вы увидите внизу окно Здесь будет видна иерархия всего Solution. В моем случае это отдельная dll библиотека и проект. Когда развернем библиотеку, мы увидим следующий уровень иерархии, и так далее Теперь давайте разберемся со столбцами дальше. 1. Maintainability Index – это комплексный показатель качества кода. Эта метрика рассчитывается по следующей формуле: MI = MAX(0, (171 — 5.2 * ln(HV) — 0.23 * CC — 16.2 * ln(LoC)) * 100 / 171) HV – Halstead Volume, вычислительная сложность. Чем больше операторов, тем больше значение этой метрики; CC – Cyclomatic Complexity (Эта метрика описана ниже); LoC – количество строк кода (Эта метрика описана ниже). 2. Cyclomatic Complexity – показывает структурную сложность кода. Иными словами, количество различных ветвей кода. Считается на основе операторов в Вашем коде, строя графы переходов от одного оператора к другому. К примеру, оператор if-else увеличит эту метрику, потому что здесь будут разные ветви выполнения. 3. Depth of Inheritance – глубина наследования. Для каждого класса эта метрика показывает, насколько глубоко он в цепочке наследования. 4. Class Coupling – указывает на зависимость классов друг от друга. Проект с множеством зависимостей очень трудно и дорого поддерживать. 5. Lines of Code – количество строк кода. Напрямую используется редко. В наши дни, с множеством разнообразных как подходов к программированию, так и языков, эта метрика дает нам мало полезной информации. Если брать во внимание отдельный метод, то можно разбить его на несколько методов поменьше. Использования метрик Изначально стоит обращать внимание на Maintainability Index. Старайтесь придерживать его около 70-90. Это значительно облегчит сопровождения кода как Вами, так и другими программистами. Иногда стоит оставить его на уровне 50-60, так как переписать некоторые участки кода бывает очень затратным. Оценивайте здраво как код, так и Ваши возможности с затратами. Стоит также уделить много внимания Class Coupling. Эта метрика должна быть как можно меньшей. Ведь она так же способствует поддержке кода. Для оптимизации возможно придется пересматривать дизайн проекта и некоторые архитектурные решения. Теперь стоит уделить внимание Cyclomatic Complexity. Эта метрика показывает сложность кода, а это так же влияет на поддержку кода в будущем. Иногда приходится переписывать куски кода, которые писали до Вас другие люди, так как Вы просто не можете понять, что, как и зачем в этом методе. Конечно, этому еще способствует стиль кода и идея, но не забывайте о Cyclomatic Complexity при рефакторинге. Критика А теперь вернемся к критике. Вы, наверняка, заметили, что мы использовали на практике не все метрики, но они могут быть частью остальных, как в случае с Maintainability Index. Но стоит понимать, что оценивать качество работы программиста, исходя из метрик, нельзя. Это очень неточно и поверхностно. Иногда просто нет другого способа решения задачи, а иногда это бывает затратным. Также есть человеческий фактор, о котором не стоит забывать. Метрики бывают искаженными, ведь программист может стремится написать не эффективное и правильно решение, а оптимизировать показатели этих же метрик. Вывод С таким инструментом в руках Вы можете быстро и относительно легко сделать review проекта и найти его уязвимые места. Также можно постоянно мониторить метрики и делать даже некие выводы об усталости работника или его отношении к работе. Более того, можно увидеть динамику роста качества кода каждого программиста. Но здесь стоит отчетливо понимать все детали так, как мы говорили об этом в критике. Ну и одно из самых важных, следить за недопустимыми значениями, при которых хорошо было бы провести рефакторинг кода.

Введение В нашей стране в последнее время существует большая проблема с трудоустройством, особенно среди недавних выпускников и молодых специалистов. Именно поэтому был создан проект Labitex – специализированная IT-биржа труда, помогающая соискателям, связанным с IT-сферой, успешно найти работу. В этой статье будут рассмотрены основные трудности и мелочи, с которыми сталкивается соискатель при поиске работы. В чем специфика IT-биржи труда, чем она отличается от рекрутингового агентства Задача рекрутингового агентства – находить работу. У IT-биржи труда задача другая. Она предлагает работу, но, в то же время, если соискатель не подходит работодателю по уровню знаний, биржа труда отправляет его на повышение квалификации. Биржа труда – не только буфер между соискателем и работодателем, она предоставляет обучение в партнерских учебных центрах. Проект Labitex работает со школами, техникумами, вузами, учебными центрами и с IT-компаниями. С чего начинается знакомство соискателя с нами Самое простое, с чего можно начать – составление профессионального резюме. Ведь немногие знают, как оно должно выглядеть, как правильно его создать. Наш отдел HR помогает составить резюме. При составлении резюме нужно уделять внимание как его форме, так и содержанию. Существует много способов оформления, структурирования и форматирования резюме. Стоит помнить, что неправильно оформленное и недостаточно информативное резюме служит причиной отказа в 40 % случаев. И наоборот, хорошо составленное CV может показать сильные стороны даже не очень опытного кандидата и заинтересовать работодателя. Labitex в процессе работы с IT-компаниями знает, какую информацию хочет видеть работодатель, как в резюме подчеркнуть свои сильные стороны и скрыть слабые. Оформление социальных сетей Проблема в том, что соискатели не до конца понимают важность своих социальных профилей, того, как они выглядят. Они не знают, что социальные сети просматриваются работодателем всегда. Специалисты Labitex консультируют, каким должен быть контент и фотографии, говорят о том, что нужно указывать опыт работы, ведь многие используют социальные сети совсем не для того, чтобы показать свои достижения. Также необходимо иметь аккаунт в сети LinkedIn. Каждый HR знает, что в этой социальной сети тоже ищут сотрудников. Профайл в LinkedIn – неотъемлемая часть при поиске работы, тем более в сфере IT. Собеседование с HR Шутя, в Labitex называют эту услугу велотренажером. Структура собеседования в IT-компании такая: сначала соискатель проходит собеседование с HR, это как сито, где оставляют нужных подходящих людей, а остальных отправляют домой. Все должны понимать, что HR не может принять на работу. Функция HR –передать человека на собеседование дальше техническому специалисту, либо же отказать. Сам HR не может принимать решения о приеме на работу. Немногие представляют, что такое собеседование с HR, чего будет ждать HR, что кандидат должен говорить. Собеседование с HR в Labitex – репетиция собеседования. Наш HR объяснит, для чего он задает определенные вопросы, как он будет пользоваться полученной информацией, на что будет обращать внимание, а на что нет. После этого соискателю намного проще, так как когда он приходит на боевое собеседование с HR, он уже четко понимает, чего от него хотят и что он будет говорить. Собеседование – не экзамен, который Вы можете либо сдать, либо нет. Это исключительно договор о партнерстве двух сторон. Не стоит бояться собеседования. Нужно понимать, чего Вы хотите от компании и что она может дать Вам. Семинары Мы работаем над интересностью, полезностью, функциональностью семинаров. Самый ключевой семинар, он же и самый сложный, длится около 6 часов и называется «Правильное составление резюме и как пройти первое собеседование в IT-компанию». На нем мы рассматриваем, как составить резюме, что в нем должно быть и чего не должно быть. Все участники семинара заполняют анкеты, которые потом мы трансформируем в резюме, оформленное согласно требованиям работодателя. Многие даже не понимают, как оно должно выглядеть, потому что этого никто не объясняет. Мы говорим о форме и содержании. На этом же семинаре мы также рассматриваем, как пройти собеседование с HR, что захочет услышать HR от соискателя, что соискатель должен спрашивать у HR. Помощь персонального ассистента Чтобы получить работу, кандидат должен многое знать и многое уметь. Labitex сотрудничает с учебными центрами, потому что для нашей компании очень важно, чтобы на выходе из учебных центров все специалисты были качественно подготовлены. Конкуренция велика, рынок IT переполнен. Поэтому специалист должен быть квалифицирован и понимать, что от него будут требовать. Персональный ассистент работает во всех наших партнерских учебных центрах, ассистент – личный помощник, он как тренер в спортзале, который будет контролировать Ваш индивидуальный процесс обучения. Изначально персональный ассистент формирует план обучения, а также контролирует его выполнение. Он рисует timeline, может наглядно показать, для чего учиться, сколько нужно учиться и что студент получит по окончанию обучения. Персональный ассистент регулярно звонит, пишет своим клиентам. Процентов тридцать студентов учебных центров не понимают, для чего они учатся,  кем они хотят быть. Персональный ассистент создан для того, чтобы поддерживать в процессе обучения, а также контролировать качество обучения. Например, timeline может перемещаться из-за невыполнения домашних заданий. Персональный ассистент также оказывает помощь в выполнении домашних заданий. Ведь не всегда во время обучения все понятно, и нужен человек, способный объяснить сложные моменты. Также персональный ассистент составляет план стажировки. Реальность такова, что junior-специалист должен иметь опыт работы от двух лет. Выпускник университета не может пойти на должность junior-а, потому что у него нет такого опыта. Это замкнутый круг. Labitex предоставляет необходимый опыт. Когда персональный ассистент рисует timeline, студент понимает, что у него есть, к примеру, шесть месяцев для того, чтоб выучиться. А ассистент понимает, что у него есть шесть месяцев, чтобы найти стажировку. Средняя стажировка начинающего специалиста в сфере IT – 4-5 месяцев. Персональный ассистент приходит в компанию-партнер и договаривается о такой стажировке для своего клиента. Если Labitex берется за обучение кандидата, из него готовят качественного перспективного сотрудника IT-компании. Вывод В статье было рассмотрено, что мешает соискателю получить работу в желаемой IT-компании: неправильно составленное резюме, плохо оформленные социальные сети, страх и неумение проходить собеседование с HR-специалистом, недостаток знаний, низкий уровень квалификации, отсутствие опыта работы. Также рассмотрели услуги HR-специалистов, помогающие устранить проблемы и добиться желаемой должности соискателем.

Фрилансеры не всегда заключают договор на разработку сайта с заказчиками, полагаясь на договоренности, озвученные устно или сформулированные в переписке. Ведь сам процесс согласования и подписания документов занимает определенное время и требует усилий. Впрочем, сотрудничество на доверии достаточно рискованно для обеих сторон. Кроме того, что один из участников может безнаказанно отказаться от выполнения своих обязанностей, есть немало нюансов, которые затрудняют сотрудничество в случае отсутствия документально заверенных алгоритмов работы. Даже когда обе стороны намерены добросовестно выполнить все договоренности, их может подвести банальное недоразумение. Договор не только гарантирует защиту как исполнителя, так и заказчика. Он представляет собой определенную дорожную карту, которая описывает каждый этап работ, каждую возможную ситуацию, действия партнеров в случае форсмажоров и алгоритм урегулирования спорных вопросов. Даже подписание типового договора частично уменьшает риски, но мы все же рекомендуем создавать отдельный контракт для каждого заказчика. Хостинг-провайдер и регистратор доменных имен Cityhost.ua предлагает читателям нашего блога материал, созданный совместно с IT-юристами, чтобы разобраться во всех аспектах создания договора на разработку сайта. Этапы согласования и заключения договора Заключение договора начинается в момент, когда заказчик и исполнитель обсуждают и согласовывают все детали проекта. Поэтому этот этап также должен быть задокументирован в виде брифа. Кроме того, нужно составить детальное ТЗ и сформировать сам договор. Давайте рассмотрим каждый шаг по этому пути. Заполнение брифа Заказчики очень не любят заполнять бриф и пытаются пропустить этот этап, обсудив все детали по телефону или в чате. Часто случаются ситуации, когда заказчик говорит: «Вы профессионал, посмотрите сами, что там нужно сделать и изложите свои предложения». Такая позиция нередко выливается в результат: «Нет, это не то, что нужно, предложите что-нибудь другое». На самом же деле бриф необходим для сотрудничества, потому что в нем содержатся ответы на важные для исполнителя вопросы. Каждый разработчик заключает свой бриф, который может выглядеть подобным образом: Название и отрасль работы компании. Целевая аудитория. Локация (местная, всеукраинская, международная). Ценности, миссия. Корпоративный стиль — слоган, корпоративные цвета, стиль промо-материалов (желательно отправить эти материалы на почту). Тип сайта, который хотите заказать (визитка, интернет-магазин, корпоративный сайт, наличие/отсутствие блога и т.п.). Ориентировочная структура сайта, названия разделов. Пожелания по оформлению сайта. Примеры сайтов, на которые вы хотели бы ориентироваться. Можно создать типичный бриф, но все же стоит вносить в него дополнительные вопросы, предназначенные для конкретного заказчика. Составление технического задания После заполнения брифа заказчик уточняет вопросы и вносит предложения, каким он видит будущий сайт — основную концепцию, количество разделов, визуальный стиль. На основе этих переговоров составляется техническое задание и одновременно начинается разработка договора. В техзадании прописывается конкретный результат и все услуги, предоставляемые разработчиком. Это очень важно, поскольку «сделать сайт» довольно размытое понятие. Может случиться, что владельцы фирмы обратились к фрилансеру, который только пишет код, и не занимается дизайном и контентом. Он будет ждать от заказчика макет, тексты и фото. Другие фрилансеры могут сделать сайт «под ключ» и имеют разветвленную сеть субподрядчиков — дизайнеров, копирайтеров, фотографов и т.д. Техзадание прописывается максимально подробно и включает в себя измеряемые параметры, например: «Сайт должен состоять из 5 разделов: главная страница, страница «О нас», страница контактов, страница для представления товара, раздел для блога». Если у сайта есть блог или раздел новостей, в ТЗ также пишется, должен ли исполнитель заполнить этот раздел 2-3 новостями или делает только структуру блога. Чем подробнее будет описан каждый аспект разработки сайта, тем меньше остается места для недоразумений. Обсуждение и согласование текста договора Для начала нужно определиться с типом договора. Есть два типа — договор на оказание услуги и договор подряда. Они отличаются тем, что в первом случае ключевым является сам процесс работы, а во втором — результат. К примеру, SEO-продвижение не имеет конечного результата и продолжается всегда, пока существует сайт — тогда заключается договор на сотрудничество. Для разработки сайта больше подходит договор подряда, поскольку заказчику нужен сайт, его интересует завершенная работа и его плоды. Далее нужно поочередно прописать все главные этапы сотрудничества: Предоставление заказчиком материалов разработчику. Это могут быть тексты, фото, видео, логотип и т.д. Создание и утверждение макета. Создание сайта. Внесение поправок. Проверка и приём работы. Подписание актов о выполнении работ. Оплата проделанной работы. Это ориентировочный список, потому что у каждого сайта могут быть свои этапы. Например, исполнитель не только разрабатывает сайт, но и проводит маркетинговые исследования, анализирует конкурентов и на основе полученной информации дает рекомендации заказчику насчет концепции сайта — это отдельный этап, который также требует усилий и влияет на формирование стоимости заказа. Основные правила составления договора Есть элементы договора, без которых он не сможет стать четким документом, дисциплинирующим стороны в процессе работы. Сроки Обязательно нужно прописать сроки выполнения каждого этапа. Если внимательно присмотреться к порядку действий, вы увидите, что часть работы зависит от исполнителя (создание сайта, внесение правок), а вторая часть — от заказчика (предоставление материалов, проверка, прием работы). Если в договоре прописана только финальная дата, когда разработчик должен сдать сайт, он может попасть во временную ловушку — сроки затянуты, но не по его вине. Также следует прописать действия сторон в случае, если кто-то из партнеров выполняет свои обязанности ненадлежащим образом. К примеру, если заказчик не осуществил прием работы в течение семи дней, она автоматически считается принятой. Прописывайте не конкретные даты, а время между этапами, например: «Разработчик обязуется предоставить начальный макет сайта в течение 4 дней с момента получения материалов». Измеримость Все пункты в договоре должны быть описаны таким образом, чтобы их можно было измерить каким-либо конкретным параметром — временем, действием, результатом. Например, обсуждение и внесение правок происходит в течение недели после того, как разработчик пришлет по электронной почте ссылку на готовый сайт на такой-то адрес (конкретный). Таким образом снижается вероятность путаницы, когда одна сторона ждет результата в Вайбере, другая пишет сообщение в Фейсбуке, а время истекает. Конкретика Очень важно прописывать четкие формулировки. К примеру, «предоставить макет сайта» — это нечеткая формулировка. А вот «предоставить макет сайта в виде проекта в Figma с доступом редактора» — это уже нечто конкретное. Также нужно прописывать, какие материалы ожидает разработчик — фотографии в формате .png с разрешением не менее 600 пикселей по ширине, тексты в формате Google Docs с открытым комментированием. Далеко не все заказчики ориентируются в компьютерных технологиях. Если ваш клиент — небольшое строительное предприятие или ФЛП, ремонтирующий велосипеды, для него не существует никаких опций по умолчанию. Поэтому конкретное и детальное описание всех требований и этапов — это скорее необходимость, иначе клиента и разработчика может ожидать много сюрпризов. Сбалансированность В договоре должны быть равномерно соблюдены права и обязанности обеих сторон. Не должно быть такого, что во всем виноват заказчик или вся ответственность лежит на исполнителе. Если какой-то этап работы зависит от действий определенной стороны — она несет ответственность за его реализацию или уплачивает неустойку (или подпадает под другие санкции) в случае невыполнения обязанностей по собственной вине. Пункты договора, требующие внимания В этот раздел вынесем те аспекты сотрудничества, о которых начинающие фрилансеры могут не знать или не уметь правильно их урегулировать. 1) Количество и порядок поправок, внесение изменений в ТЗ Важен вопрос количества возможных правок и внесения изменений в техническое задание. Лучший и проверенный метод — когда заказчик отправляет все правки в одном документе, а исполнитель вносит их сразу. Оптимально делать три круга правок; если у клиента появляются дополнительные правки, это должно оплачиваться. Такая политика в первую очередь защищает исполнителя от десятков переделок и дисциплинирует заказчика, который более продуманно решает, нужна ли эта правка. Правки должны быть конкретными и аргументированными, без формулировок наподобие «сделайте как-то иначе, но не так, как есть». Насчет ТЗ — все изменения, которые заказчик хочет внести в него уже во время работы, должны также дополнительно оплачиваться. В случае необходимости можно прописать, какие изменения и какого масштаба можно вносить, сколько стоит каждое из них. Одно дело поменять фотографию, и совсем другое, когда заказчик на финальной стадии решает заменить CMS (по факту это значит делать все заново). 2) Авторские и имущественные права Вопрос авторских прав касается как материалов, используемых на сайте при разработке, так и использования материалов сайта после завершения работ. Важно отслеживать, уникален ли контент, который предоставляет заказчик или предлагает исполнитель. Для обеспечения обеих сторон нужно прописать порядок действий по предотвращению ситуаций, когда могут быть нарушены авторские права третьих лиц или одного из участников проекта. К примеру, сторона, предоставляющая материалы, должна приобщить документы, подтверждающие право собственности на них — квитанции на приобретение фото- и видеоматериалов или другой контент. Или для упрощения процедуры можно просто отметить, что ответственность за нарушение авторского права несет сторона, предоставившая материалы. К объектам авторского права относятся название сайта, тексты, фото, видео, дизайн и код. В договоре должно быть указано, кому принадлежат имущественные и авторские права на все элементы проекта после его завершения и может ли разработчик использовать какие-либо материалы для дальнейшей работы. Для ориентира используйте Закон об авторском праве и смежных правах. 3) Сотрудничество с другими подрядчиками Сайт состоит из многих компонентов, и не все работы подрядчик может выполнить самостоятельно. Если он обращается к субподрядчикам для создания дизайна или текстов, это также должно быть зафиксировано в договоре. Но в любом случае за качество конечного результата отвечает исполнитель. 4) Ответственные лица за коммуникацию с исполнителем Этот момент особенно стоит внимания, если компания-заказчик большая, в ней есть много разных отделов и работников. Скорее всего, исполнитель не будет работать напрямую с директором, а будет общаться с кем-то из менеджеров. В таком случае договор должен содержать ФИО, должность и контакты лица, ответственного за коммуникацию. Не мешает указать, какие каналы общения считаются официальными — ими могут быть не только почта, но и аккаунт в Телеграме или страница в Facebook. В случае, если разные аспекты будут согласовываться с разными людьми, это также должно быть указано. Например, за финансовые вопросы отвечает бухгалтер, за согласование макета — дизайнер компании, все остальные вопросы — к менеджеру. Но все же лучше, когда проект курирует один конкретный человек и несет ответственность за своевременную и эффективную коммуникацию. 5) Форсмажерные обстоятельства Бывают ситуации, когда кто-то не может выполнить свои обязанности по не зависящим от него причинам. На этот случай следует вынести отдельным пунктом преодоления форсмажорных обстоятельств: что можно считать такими обстоятельствами и порядок действий в случае их возникновения (например, отсрочка для исполнителя для завершения работ или отсрочка оплаты для заказчика). Обычно в этот список входят пожары, стихийные бедствия, боевые действия, забастовки, введение карантина и другие обстоятельства, которые нельзя предусмотреть и подготовиться к ним. 6) Финансовые вопросы В эту категорию входит не только порядок оплаты за проделанную работу (аванс, гонорар), но и сопутствующие расходы. Сюда можно отнести оплату домена и хостинга, заказы текстов, дизайна, фотосъемки и т.д. Исполнитель может эти расходы включить в сумму гонорара, но можно положить их и на заказчика. Это все обсуждается и прописывается. Также в договоре должны быть зафиксированы такие моменты, как порядок налогообложения, расчетная валюта, счета для получения средств, порядок перечисления и способ подтверждения получения средств исполнителем. 7) Прием работы или отказ от него На проверку и прием работы выделяется определенный срок, в течение которого заказчик может выдвинуть обоснованные замечания и требования по доработке сайта или отказаться принять работу, предоставив четкие аргументы. Отказаться от приема работы можно только в случае, если сайт не отвечает технической задаче, выполнен с нарушением законов или имеет другие объективные недостатки, которые делают невозможным его использование и которые можно доказать. Не могут быть учтены субъективные аргументы, когда сайт исполнен по всем договоренностям, но разработчик представлял себе его как-то иначе. Если разработчик выполнил все пункты ТЗ и договор, клиент не может отказаться от подписания акта. В случае, если речь идет о масштабных проектах с большой суммой оплаты, советуем обратиться за консультацией к юристу, который поможет прописать договор максимально четко и избежать «лазеек» для двойной трактовки.

Этап 1: Планирование Этап 2. Определение необходимых типов тестирования мобильных приложений Этап 3: Тестовые случаи и разработка сценариев тестирования приложения Этап 4: Ручное и автоматическое тестирование Этап 5: Тестирование юзабилити и бета-тестирование Этап 6: Тестирование производительности Этап 7: Аттестационное тестирование и тестирование безопасности приложения Этап 8: Тестирование устройства Этап 9: контрольный этап и резюме Вывод Ваш пошаговый алгоритм тестирования мобильных приложений Обеспечение качества (QA, от английского - Quality Assurance) является неотъемлемой частью жизненного цикла разработки любых приложений, включая мобильные. К сожалению, многие упускают из виду критические особенности тестирования мобильных приложений, которые часто приводят к сбоям, ошибкам в работе приложения и плохому качеству обслуживания клиентов. Чтобы обеспечить успешную разработку любого приложения, специалист-тестировщик должен принимать участие во всех этапах разработки - от создания концепции и анализа требований, до создания спецификаций тестирования и выпуска готового продукта. Обеспечение качества также является ключевым элементом в последующих, после прохождения этапов разработки, обзорах программного продукта. Однако часто бывает сложно определить, с чего начать организацию процесса тестирования мобильного приложения. Для беспроблемного тестирования мы рекомендуем просто выполнить девять указанных ниже шагов. Давайте рассмотрим особенности тестирования мобильных приложений. Цикл жизни спринтов Этап 1: Планирование Когда этап разработки приложения почти завершен, вы должны снова поставить перед собой вопрос - чего вы пытаетесь достичь разработкой данного приложения и какие у вас есть ограничения. Вы должны определить следующее: Взаимодействует ли ваше приложение с другими приложениями? Насколько функциональны все возможности приложения? Является ли тестируемое мобильное приложение нативным, Mobile-web или гибридным? Ограничена ли задача тестирования приложения тестированием только внешнего интерфейса? Стоят ли задачи на тестирование бэкенда? Какова должна быть совместимость с различными беспроводными сетями? Как сильно данные приложения и свободное пространство, занимаемое им, зависят от особенностей использования приложения? Насколько быстро загружается ваше приложение, насколько быстро происходит серфинг по меню приложения и его функциям? Как будет обрабатываться возможное увеличение нагрузки на приложение? Влияют ли различные изменения в статусе и состоянии телефона на работу мобильного приложения? Убедитесь, что вы договорились с командой тестировщиков о роли каждого из них и о ваших ожиданиях от процесса тестирования. В конце концов, общение является ключом к поддержанию правильной рабочей среды в команде. Правильное понимание ролей и задач также относится и к моменту прописывания списка тест кейсов. Вся команда QA должна поддерживать и обновлять этот документ с отчетами по тестированию всех функций, реализованных на протяжении всего процесса разработки.   Этап 2. Определение необходимых типов тестирования мобильных приложений Перед тестированием любых мобильных приложений определите, что именно в данном мобильном приложении вы хотите протестировать: набор функциональности, удобство использования, совместимость, производительность, безопасность и т. д. На этом же этапе имеет смысл выбрать методы тестирования мобильного приложения. Определите, на какие целевые устройства направлено данное приложение, и какие требования  к функционалу следует проверить. Вы также должны определить, какие целевые устройства нужно включить в список тестирования. Вы можете сделать это следующим образом: • Выяснить, какие устройства будет поддерживать приложение; • Определить, какая версия операционной системы будет самой ранней из тех, что  поддерживаются приложением; • Выявить наиболее популярные модели мобильных устройств у целевой аудитории; • Определить набор не основных (дополнительных) устройств с экранами разных размеров, потенциально  поддерживаемых приложением; • Решить, будете ли вы использовать для тестирования физические устройства или их эмуляторы. Этап 3: Тестовые случаи и разработка сценариев тестирования приложения Подготовьте документ, описывающий тестовые случаи (test cases) для каждой тестируемой функции и функциональности. В дополнение к функциональным тестовым случаям, также должны быть охвачены некоторые отдельные моменты (кейсы): • Особенность использование батареи; • Скорость работы приложения; • Требования к данным; • Объем используемой памяти. Также перед началом тестирования важно определиться, какое сочетание ручного и автоматического тестирования вы будете применять. При необходимости подготовьте отдельные наборы ручных тестовых случаев и сценариев для автоматического тестирования и адаптируйте их согласно требованиям проекта.   Этап 4: Ручное и автоматическое тестирование Теперь пришло время для выполнения ручных и автоматизированных тестов. Ранее, на предыдущих этапах, вы уже определили, какие тесты и скрипты использовать и подготовили их. Теперь, на текущем этапе, вы выполняете запуск тестов для проверки механизмов основной функциональности, чтобы убедиться в отсутствии поломок. Автоматизированное тестирование мобильных приложений хорошо экономит время и другие ресурсы тестировщиков.   Этап 5: Тестирование юзабилити и бета-тестирование После того, как базовый функционал протестирован, настало время убедиться, что мобильное приложение является достаточно простым в использовании и обеспечивает удовлетворительный пользовательский опыт. На этом этапе необходимо поддерживать соответствие матрице кроссплатформенности, чтобы обеспечить охват пользователей различных платформ, достигнутый бета-тестерами. Пример матрицы поддержки разных версий платформы iOs После того, как приложение будет протестировано внутри компании, вы сможете выпустить бета-версию приложения на рынок. Тестирование совместимости Мобильные устройства различаются в зависимости от платформы, модели и версии их операционной системы. Важно выбрать такое подмножество устройств, которое будет соответствовать вашему приложению. Тестирование пользовательского интерфейса Пользовательский опыт является ключевым элементом, при тестировании приложения. Ведь наше приложение разрабатывается именно для конечных пользователей. Вам следует качественно проверить удобство использования приложения, навигацию по его элементам и контент. Тестируйте меню, опции, кнопки, закладки, историю, настройки и навигацию приложения. Тестирование интерфейса Тестирование пунктов меню, кнопок, закладок, истории, настроек и навигации по приложению. Тестирование внешних факторов Приложения для мобильных устройств не будут единственными приложениями на устройстве пользователя. Вместе с вашим приложением будут установлены приложения от сторонних разработчиков. Возможно десятки таких приложений. Следовательно, вашему приложению придётся взаимодействовать с этими сторонними приложениями и прерывать работу различных функций устройства, таких как различные типы сетевых подключений, обращение к SD-карте, телефонные звонки и другие функции устройства. Тестирование доступности Мобильными устройствами могут пользоваться различные люди с ограниченными возможностями. По этой причине важно  протестировать возможность работы с приложением людей с дальтонизмом, нарушениями слуха, проблемами пожилого возраста и другими возможными проблемами.  Такое тестирование является важной частью общего тестирования юзабилити.   Этап 6: Тестирование производительности Мобильные устройства предоставляют для приложений меньший объем памяти и меньшую доступную мощность процессора, чем стационарные компьютеры и ноутбуки. По этой причине в работе мобильных приложений очень важна эффективность использования предоставляемых ресурсов. Вам следует проверить работоспособность тестируемого приложения, изменив соединение с 2G, 3G на WIFI, проверить скорость отклика, потребление заряда батареи, стабильность работы и т. д. Рекомендуется проверять приложение на предмет масштабируемости применения и наличие возможных проблем с производительностью. В рамках этого этапа важно пройти и нагрузочное тестирование мобильного приложения.   Функциональное тестирование Функциональность приложения должна быть полностью протестирована. Особое внимание следует уделить установке, обновлениям, регистрации и входу в систему, обеспечению, работе со специфическими функциями устройства и сообщениям об ошибках. Функциональное тестирование мобильного приложения, по большей части, может быть выполнено так же, как вы выполнили бы его для любого другого типа приложения. По этой причине мы не будем вдаваться в подробности этого типа тестирования. Однако следует указать области, которые имеют особое значение для мобильных приложений. Имейте в виду, что функциональное тестирование должно включать в себя тестирование всех функций приложения и не должно быть излишне сосредоточено на какой-то одной функции. В рамках функционального тестирования, вам следует выполнить следующие тесты: • Тестирование процесса установки; • Тестирование возможности обновлений; • Эксплуатационное тестирование; • Тестирование процесса регистрации и авторизации; • Тестирование функций, специфических для устройства; • Тестирование отправки и получения сообщений об ошибках; • Низкоуровневое тестирование ресурсов: использование памяти, автоматическое освобождение ресурсов и т.д. • Тестирование сервисов: функционирование как в режиме онлайн, так и в автономном режиме. Этап 7: Аттестационное тестирование и тестирование безопасности приложения Безопасность и конфиденциальность данных имеют огромное значение в наше время. Пользователи требуют, чтобы вся их информация хранилась безопасно и конфиденциально. Убедитесь, что тестируемое приложение надежно защищено. Выполните проверку на возможность внедрения SQL инъекций, на возможность перехвата сеансов, анализа дампов данных, анализа пакетов и SSL трафика. Очень важно проверить безопасность хранилища конфиденциальных данных вашего мобильного приложения и его поведение в соответствии с различными схемами разрешений для устройств. Помимо проверки безусловного шифрования имен пользователей и паролей, задайте себе следующие вопросы: • Есть ли у приложения сертификаты безопасности? • Использует ли приложение безопасные сетевые протоколы? • Существуют ли какие-либо ограничения, например количество попыток входа в систему до блокировки пользователей?   Этап 8: Тестирование устройства Выполните тесты по тем алгоритмам, которые вы ранее прописали в тестовых случаях и сценариях тестирования на всех определенных для тестирования устройствах, в облаке и / или на физических устройствах.   Этап 9: контрольный этап и резюме Этот этап включает в себя подробное и полное тестирование - от ранних итеративных этапов тестирования до регрессионных тестов, которые все еще могут потребоваться для стабилизации работы приложения и выявления незначительных дефектов. На этом этапе тестирования вы можете добавить для проверки новые функции и изменить настройки на те, которых не будет в финальной версии. После завершения тестирования приложения, дополнительные параметры и функции, добавленные для проверки на этом этапе, удаляются, и окончательная версия становится готовой для представления общественности. Итоговый отчет о тестировании Весь процесс тестирования мобильных приложений должен быть тщательно задокументирован. Проверьте дважды, сделаны ли нужные записи, и после этого сформируйте свой окончательный отчет о тестировании (test summary report). Этот отчет должен включать: • Важную информацию, выявленную в результате проведенных испытаний; • Информацию о качестве проводимого тестирования; • Сводную информацию о качестве тестируемого мобильного приложения; • Статистику, полученную из отчетов об различных инцидентах; • Информацию о видах тестирования и времени, затраченном на каждый из них. Следует также указать в отчете, что: • данное мобильное приложение пригодно для использования в том качестве, в котором заявлено; • соответствует всем критериям приемлемости функционала и качества работы. Вооружившись сводкой, руководство проекта теперь может решить, готово ли мобильное приложение к выпуску на рынок. Тестирование мобильных приложений - сложная задача. Приспосабливая эти этапы тестирования к каждому разрабатываемому приложению и тщательно выполняя каждый шаг - вы гарантированно получите полнофункциональный качественный продукт. Вывод В данной статье мы рассмотрели особенности тестирования мобильных приложений. Рассмотренные этапы тестирования важны и для тестирования андроид приложений и как ответ на вопрос как тестировать приложения для iphone. Важно помнить, что тестирование приложений перед представлением на рынке – важный этап в разработке любых приложений. И, конечно же, тестирование мобильных приложений имеет свои особенности и важные моменты. Ответственно подходите к вопросу разработки и тестирования мобильных приложений, своевременно изучая и применяя актуальные методики и технологии. С нашей стороны мы рекомендуем для изучения курс на ITVDN - Unit тестирование для Android разработчиков. По материалам статьи. Также Вам могут быть интересны: Видео курсы по специальности Quality Assurance Видео курсы по специальности Android Developer Видео курсы по специальности iOS Developer