Для чего используется Jira?

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

Приложение Atlassian построено по принципам канбан / скрам–досок.

Канбан – это методика планирования задач, разработанная в сороковых годах. Суть канбан–доски заключается в наглядном расположении задач в соответствии с их статусом. Типичная доска делится на 3 колонки:

– Задачи, которые необходимо выполнить (обычный TODO–лист);

– Задачи, которые в текущий момент находятся в работе;

– Задачи, которые уже выполнены и висят на доске исключительно для отслеживания прогресса.

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

Чем отличается HTTP от HTTPs?

HTTP использует в работе порт 80, а HTTPs — порт 443. Так принято для удобства. Но главное отличие этих двух протоколов в том, что по HTTPs безопасно передавать личные данные, а по HTTP — нет.

Если злоумышленник перехватит трафик, отправленный по протоколу HTTP, он сможет увидеть всё, что вы ввели на сайте: контактную информацию, логин и пароль, детали банковской карты. Чтобы не раскрыть конфиденциальные данные, нужно вводить их только на тех сайтах, которые работают по HTTPs. Используемый протокол всегда можно посмотреть в адресной строке браузера.

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

Лайфхак для разработчиков – если кодить под водой, то никто не увидит, как вы плачете 😄

Что такое коды состояния HTTP и зачем они нужны?

Код состояния HTTP (англ. HTTP status code) – это трёхзначное число, с которого начинается любой ответ сервера на запрос по протоколу HTTP. Код кратко сообщает суть ответа – был ли выполнен запрос или возникла ошибка.

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

Коды ответов HTTP делятся на пять классов. В каждом из них объединены сообщения с похожими значениями. Вот краткие описания каждого из классов:

1хх – информационные коды. Сообщают о прогрессе выполнения запроса. На практике практически не встречаются;

2хх – коды успешно выполненных запросов. Сообщают о том, что всё в порядке и работает, как ожидалось;

3хх – коды перенаправлений. Сообщают о том, что запрашиваемая страница переехала и нужно сделать ещё один запрос по новому URL;

4хх – коды ошибок клиента. Сообщают об ошибке на стороне пользователя, который отправил запрос;

5хх – коды ошибок сервера. Сообщают об ошибке на стороне сервера, который обрабатывал запрос.

Что такое Garbage Collector в Java?

Перейдем с вами к большой теме под названием Garbage Collector.

Поиском и освобождением ненужных участков в памяти в JVM занимается специальный процесс, который называется Garbage Collector или коротко GC. У Garbage Collector всего две задачи – это обнаружение и очистка мусора.

Мусор – это структура данных (объект) в памяти не достижимый из программного кода.

Существует несколько реализаций GC, работающих по различным алгоритмам, каждый из которых по своему решает проблему отслеживания и уничтожения уже ненужных объектов (рассмотрим разные реализации в будущих постах).

По спецификации нет никаких правил для реализации GC, кроме соблюдения корректности – это значит, что нельзя собирать объекты, которые в будущем в приложении будут использоваться.
Я уже много раз сказал слово "ненужные" объекты. Но как определить, что объект не нужен, что объект не используется и это мусор?

Существует несколько подходов для поиска мусора:

– Reference counting
– Tracing

Поговорим об этих подходах в следующих постах.

Garbage Collector. Reference Counting. Часть 1.

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

Из плюсов данного подхода можно выделить несколько: простота, не требуются долгие паузы для сборки мусора.

Однако, есть и  существенные минусы:

– Плохо сочетается с многопоточностью;

– Сложно выявлять циклические зависимости;

– Влияет на производительность – каждый раз, когда мы что-то читаем, записываем ссылку на объект в локальную переменную, нам нужно увеличивать счетчик.

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

Garbage Collector. Reference Counting. Часть 2.

Одним из минусов подхода Reference Counting является сложность выявления циклических зависимостей.

Циклические зависимости – когда два объекта указывают друг на друга, но ни одна ссылка из Stack на них не ссылается. Это приводит к утечкам памяти. Наглядно можно посмотреть на картинке – каждый из объектов на рисунке имеет по одной ссылке на себя, однако только один является по-настоящему "живым" и нужным.

Когда один из твоих юнит–тестов не прошел один раз из сотни, а ты все это время ничего не менял

На собеседованиях Java–разработчиков и стажеров часто спрашивают о том, какие бывают GC Root?

Как мы уже поняли из предыдущего поста с примером c Person – локальные переменные являются GC Root.

Компилятор вычисляет для всех переменных live ranges – это всё, что находится на любых путях исполнения от определения переменной до последнего использования (или использований, они могут быть разные на разных путях).

Другими словами, компилятор всегда знает: жива сейчас переменная или нет, могут ее потенциально в будущем еще использовать или нет.

GC тоже ориентируется на это знание от компилятора. Если переменная вне своего live range, то значит она уже не будет корнем.

Но что еще может быть корневой точкой?
Корневой точкой могут быть:

– Локальные переменные и параметры методов;

– Потоки Java;

– Статические переменные;

– Ссылки из JNI.

Из этого следует, что даже самое простое java приложение имеет следующие GC Root:

– Локальные переменные внутри main метода;

– Статические переменные класса, содержащего main метод;

– Параметры main метода;

– Поток, который выполняет main метод.

Алгоритмы очистки памяти. Copying collectors.

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

Рассмотрим Copying collectors.

Память условно делится на две области: from–space и to–space.
Все объекты создаются в области from–space, по мере заполнения этой области запускается очистка мусора. Приложение полностью останавливается – происходит так называемый stop–the–world – в момент начала очистки, после чего все "живые" объекты в from–space копируются в to–space.
После того, как все "живые" объекты скопированы происходит полная очистка from–space и области меняются местами.

Stop–the–World – это остановка любой мутирующей heap активности.

Из плюсов можно выделить то, что объекты плотно забивают память, поэтому tracing происходит быстрее.

Из минусов можно отметить полную остановку приложения и то, что у нас одна область памяти, по сути, не используется, а при большом количестве объектов это проблема.

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

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

Когда кто-то из коллег открыл IDE со светлой темой

Реализации Garbage Collector.

– Serial GC
Это последовательная сборка молодого и старого поколения в области памяти Java.

– Parallel GC
Работает также как и Serial GC, но с использованием многопоточности.

– CMS GC (Concurrent Mark–and–Sweep)
Для сборки мусора задействуются несколько потоков, и происходит это через такой же алгоритм, как в Parallel GC.
Использовался до Java 7 и G1.

– G1 GC
Был задуман как замена CMS и разрабатывался для многопоточных приложений, которые характеризуются крупным размером кучи (более 4 ГБ).

– Epsilon
Был выпущен как часть JDK 11. Не реализует никакого реального механизма восстановления памяти. Как только доступная куча исчерпана, JVM завершает работу.

– Shenandoah
Выпущен как часть JDK 12. Ключевое преимущество перед G1 в том, что G1 может эвакуировать области кучи только тогда, когда приложение приостановлено, а Shenandoah перемещает объекты одновременно с приложением.

– ZGC
Выпущен как часть JDK 11 и улучшен в JDK 12. Предназначен для приложений, требующих низкой задержки (паузы в менее чем 10 мс) или задействующих очень большую кучу (несколько терабайт).