Lifecycle hooks (Хуки жизненного цикла) — это очень важная часть любого компонента. Нам, нашему приложению, часто нужно знать что происходит с компонентом, когда он создан, смонтирован, обновлен или уничтожен.

В компоненте мы можем отлавливать эти события используя соответствующие методы, например:

• created — экземпляр компонента создан
• mounted — экземпляр компонента cмонтирован
• updated — виртуальный DOM был обновлён из-за изменения данных
• destroyed — экземпляр компонента уничтожен
• и т.д. Документация

В коде нашего компонента это будет выглядеть так:

Перевод статьи подготовлен для студентов курса «MS SQL Server разработчик»

---

Реляционные базы данных являются одними из наиболее часто используемых баз данных по сей день, и поэтому навыки работы с SQL для большинства должностей являются обязательными. В этой статье с вопросами по SQL с собеседований я познакомлю вас с наиболее часто задаваемыми вопросами по SQL (Structured Query Language — язык структурированных запросов). Эта статья является идеальным руководством для изучения всех концепций, связанных с SQL, Oracle, MS SQL Server и базой данных MySQL.

Эта статья — краткое руководство для тех, кто хочет запустить свой собственный подкаст. Когда я вместе с моим нынешним соведущим год назад запускал подкаст “В бесконечность и далее”, я не смог найти ни одной по-настоящему всеобъемлющей статьи. Поэтому я решил попытаться заполнить этот пробел и написать руководство для себя из прошлого.

Немного о структуре — это руководство содержит 4 статьи:

1. Общая философия
   1.1. Зачем делать подкаст?
   1.2. Целевая аудитория
   1.3. Выбор жанра
   1.4. Формат
2. Технический базис
   2.1. Что такое подкаст с технической точки зрения
   2.2. Аудио-формат
   2.3. Про динамики, наушники и ламповый звук
   2.4. Про тихое помещение
3. Делаем покупки
   3.1. Покупаем микрофон
   3.2. Выбираем аудиоредактор
   3.3. Выбираем программу для записи звука
   3.4. Выбираем хостинг подкаста
   3.5. Сайт-визитка
4. Записываем и выпускаем
   4.1. Запись выпуска
   4.2. Редактирование выпуска
   4.3. Про джинглы и звуковые схемы
   4.4. Про фоновый шум
   4.5. Про фильтры
   4.6. Про Show Notes, а также про то, зачем слушать свой подкаст
   4.7. Публикация подкаста
   4.8. Монетизация
   4.9. Темы, которые есть, но о которых мы не говорили

Каждый раздел статьи содержит три блока

• Суть раздела — основная мысль, изложенная тезисно
• Детальное описание “что, зачем и почему”. Обычно — много букв, которые поясняют основную мысль, и находятся они в скрытой секции “Дополнительная информация”
• Ответ, который нашли мы

Интересно — читайте все. Нет времени — читайте первый и последний абзац.

1. Общая философия

1.1. Зачем делать подкаст?

Ответ может быть любым, но только не “потом посмотрим”, ”ещё не думал” или “не знаю”. Если ответа нет, весьма высока вероятность что

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



Автор статьи, перевод которой мы сегодня публикуем, говорит, что команда, в которой он трудится, воодушевилась рассказом TechLead’a о 7 привычках высокоэффективных программистов. Члены команды решили высказать собственные мысли по этому вопросу. Здесь, в форме советов, приведён разбор 7 навыков эффективных программистов.

Всем привет! Уже на следующей неделе стартуют занятия в группе «Java QA Engineer». Этому и будет приурочена нынешняя публикация.

Обзор:

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

Объектно-ориентированное программирование — чрезвычайно плохая идея, которая могла возникнуть только в Калифорнии.

— Эдсгер Вибе Дейкстра

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

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

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