В статье нет ни слова о том, что гуманитарий чего-то не сможет. Сказано только, что у них нет технической базы, потому их обучение требует больших вложений со стороны работодателя.
В принципе, все практики ХР — это не панацея, применять их следует, отталкиваясь от задачи и команды. Также необязательно всегда кодить в парах, но это хорошие профилактика замыливания взгляда и способ, когда нужно писать что-то нестандартное, например. Один прокладывает направление, держа код в голове «целиком», а второй реализует конкретный кусочек. А как вы считаете, как следует практиковать парное программирование?
Это сознательный обман Заказчика вызванный сознательным/не сознательным желанием качать с него деньги.
Нет, это может быть стандартный MVP. А потом решения, принятые в MVP, остаются надолго и перестают соответствовать новым реалиям. Сомневаюсь, что создатели Инстаграма изначально закладывали в архитектуру миллионы пользователей
Суть IT разработчики не желают работать в строгом соответствии к требованиям производственного процесса.
Зачем так плохо думать о людях? Да, можно собрать много причин, почему они так делают. Например, всегда так делали раньше, у них никогда не было описанных требований производственного процесса, не было хорошего ментора. Либо в компании так не принято или не было принято. Поэтому продолжают делать в том же стиле. Может быть, требования есть только в голове архитектора, один он владеет этими сакральными знаниями. И еще масса причин, почему не пишут документацию.
Я специально отформатировал цитату чтобы яснее стали понятны Ваши приоритеты - "качество не важно, лишь бы сдать заказчику". А потом Вы начнете качать из заказчика деньги.
В процитированном сообщении как раз написано обратное. Скорость и качество — это критерии отбора «важное»/«не важное».
Другими словами, вначале мы сознательно закладываем "упрощенную архитектуру", а когда заказчик начинает понимать, что проект "ходит по граблям" начинаем ему объяснять, что устранение этих граблей это серьезная работа, которая делается за отдельные (серьезные) деньги.
Да, сознательно, на основании функциональных и нефункциональных требований. А потом, когда заказчик понимает, что за прошедшие 5 лет его требование «сделать приложение для 5 человек в день за 10 рублей» превратилось в «хочу 24 на 7 систему с 1млн запросов в день», придется переписать архитектуру и часть приложения.
Собственно еще раз Вы демонстрируете, что не создаете инструмент для который решает его задачи. А все строго наоборот Вы создаете инструмент для решения своей задачи - доить заказчика. Как написал предыдущий комментатор: Техдолг это несделанная работа. Я продолжу его мысль, несделанная работа за которую получены деньги. что в свою очередь означает оказание услуг не надлежащего качества и теоретически уголовно наказуемо.
По-моему, вы путаете понятия. Если вы сдаете проект, который не удовлетворяет требованиям (функциональным и нефункциональным) заказчика, это не техдолг. Это просто не сделанная работа, ее никак нельзя считать техдолгом. Если вы не написали документацию к одному приватному методу в классе или используете устаревший класс, то это станет техдолгом, когда из-за вас будет страдать будущая разработка. Если не страдает — это все лишь некрасивый «пахнущий» код, он глобально и отрицательно не скажется на проекте. Хорошего в этом тоже, впрочем, мало.
Все верно говорите о проценте несоответствия, он зависит от многих факторов. В большинстве проектов, с которыми мы работали, договор был на 5%.
Использовали сервисы AWS для автоматизации отчетов из почты и API, т.к. у нас весь проект на AWS и затраты по сравнению с исходящим трафиком незначительные.
Специального инструмента нет? Или Графаны хватает?
Был успешный опыт использования Grafana на других AdTech проектах. И в этом проекте решили использовать Prometheus + Grafana. Пока их хватало.
Показы и данные о показах куда собираете?
Трекер отправляет данные в AWS Kinesis Firehose и сохраняет их в S3 с разбивкой по часам. При помощи ETL (AWS Glue) считаем предагрегаты и пишем в postgreSQL. Отчеты формируются из данных в postgreSQL.
Для тестового трекера разворачивали Snowplow трекер на AWS. Тут тоже решение пишет через стрим в S3 и обработанный результат пишет в postgreSQL.
Все верно, для некоторых задач лямбды — экономия, для других — расточительство. Зависит от рода задачи. Например, админкой пользуются немногие и нечасто — много простоев — выгодно перевести на лямбды. Популярные сервисы, вроде аутентификации или предоставления данных пользователя обычно используются часто и, предполагаю, довольно загружены. Тогда вместо экономии на простое получаем более дорогой сервис в непрерывной эксплуатации. Будьте бдительны)
В статье нет ни слова о том, что гуманитарий чего-то не сможет. Сказано только, что у них нет технической базы, потому их обучение требует больших вложений со стороны работодателя.
От джунов никто кулстори не ждет. Кусочек функционала сделай, баг известный исправь — и ты молодец.
Кстати, вот есть конкурс по опенсорсу для школьников и студентов: https://foss.kruzhok.org/
В кафку постороннему и не дадут контрибьютить. Но есть десятки тысяч проектов на гитхабе, куда дадут, и где можно что-то полезное сделать даже джуну.
В принципе, все практики ХР — это не панацея, применять их следует, отталкиваясь от задачи и команды. Также необязательно всегда кодить в парах, но это хорошие профилактика замыливания взгляда и способ, когда нужно писать что-то нестандартное, например. Один прокладывает направление, держа код в голове «целиком», а второй реализует конкретный кусочек. А как вы считаете, как следует практиковать парное программирование?
Нет, это может быть стандартный MVP. А потом решения, принятые в MVP, остаются надолго и перестают соответствовать новым реалиям. Сомневаюсь, что создатели Инстаграма изначально закладывали в архитектуру миллионы пользователей
Зачем так плохо думать о людях? Да, можно собрать много причин, почему они так делают. Например, всегда так делали раньше, у них никогда не было описанных требований производственного процесса, не было хорошего ментора. Либо в компании так не принято или не было принято. Поэтому продолжают делать в том же стиле. Может быть, требования есть только в голове архитектора, один он владеет этими сакральными знаниями. И еще масса причин, почему не пишут документацию.
В процитированном сообщении как раз написано обратное. Скорость и качество — это критерии отбора «важное»/«не важное».
Да, сознательно, на основании функциональных и нефункциональных требований. А потом, когда заказчик понимает, что за прошедшие 5 лет его требование «сделать приложение для 5 человек в день за 10 рублей» превратилось в «хочу 24 на 7 систему с 1млн запросов в день», придется переписать архитектуру и часть приложения.
По-моему, вы путаете понятия. Если вы сдаете проект, который не удовлетворяет требованиям (функциональным и нефункциональным) заказчика, это не техдолг. Это просто не сделанная работа, ее никак нельзя считать техдолгом.
Если вы не написали документацию к одному приватному методу в классе или используете устаревший класс, то это станет техдолгом, когда из-за вас будет страдать будущая разработка. Если не страдает — это все лишь некрасивый «пахнущий» код, он глобально и отрицательно не скажется на проекте. Хорошего в этом тоже, впрочем, мало.
Все данные сохраняются в файл json в S3 хранилище и остаются там. А из них ETL pySpark job-а собирает агрегаты.
Все верно говорите о проценте несоответствия, он зависит от многих факторов. В большинстве проектов, с которыми мы работали, договор был на 5%.
Использовали сервисы AWS для автоматизации отчетов из почты и API, т.к. у нас весь проект на AWS и затраты по сравнению с исходящим трафиком незначительные.
Был успешный опыт использования Grafana на других AdTech проектах. И в этом проекте решили использовать Prometheus + Grafana. Пока их хватало.
Трекер отправляет данные в AWS Kinesis Firehose и сохраняет их в S3 с разбивкой по часам.
При помощи ETL (AWS Glue) считаем предагрегаты и пишем в postgreSQL. Отчеты формируются из данных в postgreSQL.
Для тестового трекера разворачивали Snowplow трекер на AWS. Тут тоже решение пишет через стрим в S3 и обработанный результат пишет в postgreSQL.
Трекеры показали похожий результат. Оставили свой.
Все верно, для некоторых задач лямбды — экономия, для других — расточительство. Зависит от рода задачи. Например, админкой пользуются немногие и нечасто — много простоев — выгодно перевести на лямбды. Популярные сервисы, вроде аутентификации или предоставления данных пользователя обычно используются часто и, предполагаю, довольно загружены. Тогда вместо экономии на простое получаем более дорогой сервис в непрерывной эксплуатации. Будьте бдительны)