Вы не правы. Невозможно писать так, чтобы технический долг не возникал, так как:
Мы все люди
В любом живом проекте меняются требования
Мы работаем не одни
Кодовая база крайне редко бывает маленькой. Да, мы все пишем код так, чтобы техдолг не возникал, но меняются подходы, наши знания, да и просто мы растем как специалисты и то, что мы 10 лет назад считали идеальным кодом сейчас не пройдет ревью.
Обновлять зависимости надо всегда, но пусть не в момент выхода, а через пару-тройку патчей.
Хороший рефакторинг это тот, который сделан своевременно. Есть как минимум 3 процесса улучшения кода: для исправления техдолга, созданного руками разработчиков, для исправления накопительных ошибок и для исправление запланированного устаревания.
На первый выделяется время в рамках ежедневной работы. Если ты можешь исправить кусок кода в рамках своей задачи - выдели на это время. Если не можешь - выдели задачу. Обычно 10% спринта можно выделить на техдолг. Второй - очень тяжелый, на него надо выделять время дважды - для обнаружения и для рефакторинга. Нет рецепта. Исправление запланированного устаревания происходит в рамках обновления библиотек, в рамках обновления фреймворков и экосистемы. Просто обновилось что-то глобальное, выделили время, обновились.
Практика переучивания достаточно распространена. Правда первый раз вижу, стобы требовалось переучиться на php. Но при этом, видел вакансии с переучиванием на го и даже на badoo tech был доклад про это.
Не могу представить сценарий, когда пользователь будет опрашивать сервер с частотой более 60 раз за минуту.
Приведите, пожалуйста, пример, может я что-то упускаю?
На эту тему высказался человек, который нанимал на работу Игоря Сысоева — Игорь Ашманов. https://www.bfm.ru/news/431897
Это был сайд-проект.
Более того, есть серьезные вопросы по поводу того, чем рамблер занимался 16 лет до этого, что не предъявил претензии ранее, а только спустя такой длительный срок.
Уволив всех, они останутся без штата опытных коллег. Кроме того, если включатся топовые разработчики компании — тимлиды, ключевые в каких-то проектах разработчики, то будет толк.
ИМХО. Забастовки устраивать не надо. Надо попробовать коллективное письмо от разработчиков, за подписью хотя бы четверти персонала, с Google в свое время это сработало, может быть сработает и с Rambler.
Сделать-то можно. Но есть вопросы корректности выполнения задачи. Да и подборка позиционировалась для фронтендеров, но 2/3 проектов без бэка не реализовать. Да и по времени немало уйдет на каждый из проектов.
Но тем не менее, например, pixel battle — интересный проект для реализации с целью научиться работать с канвасиком.
ИМХО, именно этим вы и вызвали гнев аудитории. Мало кому интересно ждать 9 дней до анонса, тратить время на пустые статьи, оставлять свои контактные данные и так далее. Тем более, что информации в этих своих анонсах анонсов вы не оставили ровным счетом никакой. Я понимаю, что NDA и коммерческая тайна, но все-таки нужно было раскрыть что за продукт, кому понадобится, какие проблемы решает, хотя бы максимально кратко. Ответ "это продукт для командной работы" максимально обширен. Git тоже инструмент для командной работы. Как и десятки других инструментов в различных сферах. Я хочу сразу понимать, стоит ли мне тратить свое время на просмотр презентации в момент ее публикации или потом посмотреть краткую выжимку из нее, или же вообще не смотреть. И каждый из комментаторов, уверен, хочет этого.
Я пользуюсь вашими продуктами несколько лет и даже несмотря на некоторые косяки, вроде долгого релиз-цикла на исправление багов, качество финального продукта — хорошее и пользоваться им удобно.
Я с удовольствием посмотрю трансляцию презентации в записи, как обычно и делаю, но вот так рьяно и по-эппловски настаивать на "посмотрииииите на нашу презентацию" и делать анонс анонса нового продукта ну это прямо нечто.
Я один из участников финала. Нет, не было.
Заперты — не совсем корректно. И не 12, а по факту дольше, так как мы после 7:30 утра (завтрак) были загнаны в зал мероприятия, а вышли полноценно только в 21. Вход выход по сканированию бейджа и под роспись. Фиксирование времени до минуты.
К слову, обед был в 4 почти, а ужин в 9. Обедали мы рисом с курочкой из стаканчиков, потому что закончилась посуда палочками для размешивания сахара в кофе. Было весело;))
UPD. Загнаны — не совсем правильное слово. Примерно с 7:30 нам по громкоговорителям настойчиво рекомендовали зайти в зал.
UPD2. Если честно, будучи на 100% погруженным в работу, редко когда хотелось выйти. Но в определенный момент хотелось прогуляться, проветрить голову.
UPD3. Спать на пуфиках — жесть полнейшая. Чтобы вы понимали, как это весело было по логистике:
Хакатон был 27, 28, 29. Вылет из моего города был в ночь на 27. Соответственно, мы не спали ночь 26-27, 27-28 спали (наша команда сняла гостиницу), 28-29 — полтора часа и проснулись с болящей спиной — пуфиков на всех не хватало и спать на них нереально, 29-30 — ночной перелет в обратно. Формально, за четыре дня мы спали 10 часов. Надо было организаторам попробовать поспать на пуфиках-каплях хотя бы в течение 2 ночей, в условиях прохладного светлого помещения, в котором постоянный гул от людей, техники и работающей вентиляции.
Совет участникам на будущее — берите с собой что-то для перекуса (батончики энергетические, ролтон и т.п.) и что-то на чем спать. Желательно матрац надувной. И чем-то чем накрыться — в зале прохладно (тут можно и курткой, в целом, но как кто хочет).
Задания, действительно, были не очень качественно составлены, по крайней мере частично. Кроме того, они переформулировались уже после того, как команды подавали на них заявки -> получалось так, что профиль участников мог с ними не совпадать. А чтобы перейти с одной категории в другую необходимо было пройти через 7 кругов ада, включая письменное обоснование такой причины, консультацию с куратором и экспертом. В общем, потеря времени, которое могло бы быть потрачено на решение задачи.
Весело было и с питанием. В первый день мы дважды стояли в очереди за талонами, потом их правда дали кураторам, чтобы они раздавали. В первый же день было адище с получением мерча и бейджей. В том числе часть из них были не распечатаны. Искать их в туче распечатанных талонов — тоже то еще удовольствие. В общем, косяков в организации было навалом. Но, в целом, это все компенсировалось относительно неплохой атмосферой и некоторыми организационными плюсами (интернет был отличный, столы, стулья, зарядки — всего хватало и было нормального качества, чай с плюшками был практически нонстопом, за исключением обеда-вечера второго дня).
Не понимаю позиции заказчика — отказ от фреймворков. Ведь ты в любом случае будешь использовать (микро)фреймворк, только самописный. Убедить не пытались? Если пытались, то как?
Расскажите, пожалуйста, подробнее.
Я просто уплыл. Этот материал можно было выразить в трех предложениях: ttfb является временем от отправки запроса до получения ответа. На него влияют такие параметры. Вы как фронтендер реально ничем не можете на него повлиять.
Мой личный список вопросов работодателю (если не было освещено на собеседовании).
Чем я буду заниматься? Только узкими обязанностями или еще и смежными?
Какой стек на моём проекте? Есть ли легаси?
Что с тестированием
Есть ли CI/CD и девопс инженер?
Будет ли единый ПМ и четко заданный жизненный цикл таска?
Есть ли БА?
Системы мониторинга, сборщик логов?
Переработки бывают? Оплата?
Системы трекинга времени и руткиты на рабочем компе?
Отпуска: дробление отпуска, включены или нет выходные, за сколько нужно предупреждать, отказы
За что и как часто получаются премии? Кто определяет их размер?
Есть ли СБ? Какие требования у СБ?
Почему открыта вакансия? Если не новая, то куда ушел предыдущий разработчик?
Аналогично про гибкий график, карьерный рост. Что это значит и в чем выражается.
Ретроспектива.
Код ревью в компании: кто, как долго, что если пожар.
Именно в этом Laravel лучше PHP, в котором нет никаких шаблонов.
Вы серьезно? Вы думаете, после подобных фраз к вам придет хоть один человек на курс? Ну вот объективно оцените свой уровень и поймите, что это полный и беспросветный ужас.
Ничего сложного. docker-compose.yml класть в то место, где ты его будешь запускать. Он ищет в той папке, где ты вызвал команду docker-compose up -d. Идентификатор lesson1 появился из названия папки в которой запускается проект. То есть автор запускал проект в папке lesson1.
Вы не правы. Невозможно писать так, чтобы технический долг не возникал, так как:
Мы все люди
В любом живом проекте меняются требования
Мы работаем не одни
Кодовая база крайне редко бывает маленькой. Да, мы все пишем код так, чтобы техдолг не возникал, но меняются подходы, наши знания, да и просто мы растем как специалисты и то, что мы 10 лет назад считали идеальным кодом сейчас не пройдет ревью.
Обновлять зависимости надо всегда, но пусть не в момент выхода, а через пару-тройку патчей.
Хороший рефакторинг это тот, который сделан своевременно. Есть как минимум 3 процесса улучшения кода: для исправления техдолга, созданного руками разработчиков, для исправления накопительных ошибок и для исправление запланированного устаревания.
На первый выделяется время в рамках ежедневной работы. Если ты можешь исправить кусок кода в рамках своей задачи - выдели на это время. Если не можешь - выдели задачу. Обычно 10% спринта можно выделить на техдолг.
Второй - очень тяжелый, на него надо выделять время дважды - для обнаружения и для рефакторинга. Нет рецепта.
Исправление запланированного устаревания происходит в рамках обновления библиотек, в рамках обновления фреймворков и экосистемы. Просто обновилось что-то глобальное, выделили время, обновились.
Другой вопрос: как можно добавлять сайты в индекс?
Практика переучивания достаточно распространена. Правда первый раз вижу, стобы требовалось переучиться на php. Но при этом, видел вакансии с переучиванием на го и даже на badoo tech был доклад про это.
Некоторым хочется чего-то нового.
Не могу представить сценарий, когда пользователь будет опрашивать сервер с частотой более 60 раз за минуту.
Приведите, пожалуйста, пример, может я что-то упускаю?
На эту тему высказался человек, который нанимал на работу Игоря Сысоева — Игорь Ашманов. https://www.bfm.ru/news/431897
Это был сайд-проект.
Более того, есть серьезные вопросы по поводу того, чем рамблер занимался 16 лет до этого, что не предъявил претензии ранее, а только спустя такой длительный срок.
Уволив всех, они останутся без штата опытных коллег. Кроме того, если включатся топовые разработчики компании — тимлиды, ключевые в каких-то проектах разработчики, то будет толк.
ИМХО. Забастовки устраивать не надо. Надо попробовать коллективное письмо от разработчиков, за подписью хотя бы четверти персонала, с Google в свое время это сработало, может быть сработает и с Rambler.
Сделать-то можно. Но есть вопросы корректности выполнения задачи. Да и подборка позиционировалась для фронтендеров, но 2/3 проектов без бэка не реализовать. Да и по времени немало уйдет на каждый из проектов.
Но тем не менее, например, pixel battle — интересный проект для реализации с целью научиться работать с канвасиком.
ИМХО, именно этим вы и вызвали гнев аудитории. Мало кому интересно ждать 9 дней до анонса, тратить время на пустые статьи, оставлять свои контактные данные и так далее. Тем более, что информации в этих своих анонсах анонсов вы не оставили ровным счетом никакой. Я понимаю, что NDA и коммерческая тайна, но все-таки нужно было раскрыть что за продукт, кому понадобится, какие проблемы решает, хотя бы максимально кратко. Ответ "это продукт для командной работы" максимально обширен. Git тоже инструмент для командной работы. Как и десятки других инструментов в различных сферах. Я хочу сразу понимать, стоит ли мне тратить свое время на просмотр презентации в момент ее публикации или потом посмотреть краткую выжимку из нее, или же вообще не смотреть. И каждый из комментаторов, уверен, хочет этого.
Я пользуюсь вашими продуктами несколько лет и даже несмотря на некоторые косяки, вроде долгого релиз-цикла на исправление багов, качество финального продукта — хорошее и пользоваться им удобно.
Я с удовольствием посмотрю трансляцию презентации в записи, как обычно и делаю, но вот так рьяно и по-эппловски настаивать на "посмотрииииите на нашу презентацию" и делать анонс анонса нового продукта ну это прямо нечто.
Я один из участников финала. Нет, не было.
Заперты — не совсем корректно. И не 12, а по факту дольше, так как мы после 7:30 утра (завтрак) были загнаны в зал мероприятия, а вышли полноценно только в 21. Вход выход по сканированию бейджа и под роспись. Фиксирование времени до минуты.
К слову, обед был в 4 почти, а ужин в 9. Обедали мы рисом с курочкой из стаканчиков, потому что закончилась посуда палочками для размешивания сахара в кофе. Было весело;))
UPD. Загнаны — не совсем правильное слово. Примерно с 7:30 нам по громкоговорителям настойчиво рекомендовали зайти в зал.
UPD2. Если честно, будучи на 100% погруженным в работу, редко когда хотелось выйти. Но в определенный момент хотелось прогуляться, проветрить голову.
UPD3. Спать на пуфиках — жесть полнейшая. Чтобы вы понимали, как это весело было по логистике:
Хакатон был 27, 28, 29. Вылет из моего города был в ночь на 27. Соответственно, мы не спали ночь 26-27, 27-28 спали (наша команда сняла гостиницу), 28-29 — полтора часа и проснулись с болящей спиной — пуфиков на всех не хватало и спать на них нереально, 29-30 — ночной перелет в обратно. Формально, за четыре дня мы спали 10 часов. Надо было организаторам попробовать поспать на пуфиках-каплях хотя бы в течение 2 ночей, в условиях прохладного светлого помещения, в котором постоянный гул от людей, техники и работающей вентиляции.
Совет участникам на будущее — берите с собой что-то для перекуса (батончики энергетические, ролтон и т.п.) и что-то на чем спать. Желательно матрац надувной. И чем-то чем накрыться — в зале прохладно (тут можно и курткой, в целом, но как кто хочет).
Задания, действительно, были не очень качественно составлены, по крайней мере частично. Кроме того, они переформулировались уже после того, как команды подавали на них заявки -> получалось так, что профиль участников мог с ними не совпадать. А чтобы перейти с одной категории в другую необходимо было пройти через 7 кругов ада, включая письменное обоснование такой причины, консультацию с куратором и экспертом. В общем, потеря времени, которое могло бы быть потрачено на решение задачи.
Весело было и с питанием. В первый день мы дважды стояли в очереди за талонами, потом их правда дали кураторам, чтобы они раздавали. В первый же день было адище с получением мерча и бейджей. В том числе часть из них были не распечатаны. Искать их в туче распечатанных талонов — тоже то еще удовольствие. В общем, косяков в организации было навалом. Но, в целом, это все компенсировалось относительно неплохой атмосферой и некоторыми организационными плюсами (интернет был отличный, столы, стулья, зарядки — всего хватало и было нормального качества, чай с плюшками был практически нонстопом, за исключением обеда-вечера второго дня).
Спасибо за ответ. А расскажите, почему именно ларовские компоненты использовались, а не симфоневые?
Не понимаю позиции заказчика — отказ от фреймворков. Ведь ты в любом случае будешь использовать (микро)фреймворк, только самописный. Убедить не пытались? Если пытались, то как?
Расскажите, пожалуйста, подробнее.
Я просто уплыл. Этот материал можно было выразить в трех предложениях: ttfb является временем от отправки запроса до получения ответа. На него влияют такие параметры. Вы как фронтендер реально ничем не можете на него повлиять.
Спасибо за впустую потраченные 5 минут.
Спасибо. Сохранил.
Вполне возможно. Мне большую часть этого списка прислал в свое время коллега, я его только слегка модифицировал.
Да, это бизнес-аналитика. Пункт связан со следующим по списку.
Мой личный список вопросов работодателю (если не было освещено на собеседовании).
Чем я буду заниматься? Только узкими обязанностями или еще и смежными?
Какой стек на моём проекте? Есть ли легаси?
Что с тестированием
Есть ли CI/CD и девопс инженер?
Будет ли единый ПМ и четко заданный жизненный цикл таска?
Есть ли БА?
Системы мониторинга, сборщик логов?
Переработки бывают? Оплата?
Системы трекинга времени и руткиты на рабочем компе?
Отпуска: дробление отпуска, включены или нет выходные, за сколько нужно предупреждать, отказы
За что и как часто получаются премии? Кто определяет их размер?
Есть ли СБ? Какие требования у СБ?
Почему открыта вакансия? Если не новая, то куда ушел предыдущий разработчик?
Аналогично про гибкий график, карьерный рост. Что это значит и в чем выражается.
Ретроспектива.
Код ревью в компании: кто, как долго, что если пожар.
Вы серьезно? Вы думаете, после подобных фраз к вам придет хоть один человек на курс? Ну вот объективно оцените свой уровень и поймите, что это полный и беспросветный ужас.
Ничего сложного. docker-compose.yml класть в то место, где ты его будешь запускать. Он ищет в той папке, где ты вызвал команду docker-compose up -d. Идентификатор lesson1 появился из названия папки в которой запускается проект. То есть автор запускал проект в папке lesson1.