Highload в ВУЗе идеализм, расчётливый менеджмент или пустые надежды / Артем К...Ontico
Highload — тот ещё секс в нашей жизни. Можно ли научить сексу заранее тех, кто не нюхал пороха?
В своей работе я часто сталкиваюсь с бойцами от разработки, управления проектами, информационной безопасности и даже эксплуатации, возможно даже опытными, с медалями первой степени, но из другого рода продуктов, из "обычного софта" что ли... Эти ребята действительно уверены, что база данных всегда ответит их приложению быстро. Они с пеной у рта доказывают, что точки интеграции с elastic'ом защищать не нужно и можно делать синхронные вызовы к нему на входе в приложение. Они обижаются, когда их приложение падает. Недоумевают, почему разбираться с этим нужно вместе — ведь на тестовой все работало, а на машине у программера, вообще, все летало!!!
И только с кровью и потом приходит понимание. Поскольку кровь и пот не только их, но и мои, я задумался: а можно ли ещё на этапе грудного вскармливания подмешать этих знаний в молодые умы? Чтоб уж, если не писали сразу с учётом боевой нагрузки, то хотя бы чтоб быстро понимали, как исправлять приложение.
Как итог: новый спецкурс на Факультете информационных технологий в НГУ.
Два года, два потока.
Переписанная два раза программа, мысли переписать снова.
Трудности с лабораторными стендами. Пошёл через облака — отдал своих кровных 5 000 за время, пока настраивал, и две пары лабораторной работы в Azure.
Отказался от идеи показать для сравнения мир Microsoft с его release manager и desired state config.
С удивлением включил в программу вопросы непрерывной интеграции, а думал говорить только про поставку.
Мясо, нужно больше мяса, но нужны помощники, где взять опытных волонтеров со сбитыми костяшками.
Мучения с погружением в кух�
Highload в ВУЗе идеализм, расчётливый менеджмент или пустые надежды / Артем К...Ontico
Highload — тот ещё секс в нашей жизни. Можно ли научить сексу заранее тех, кто не нюхал пороха?
В своей работе я часто сталкиваюсь с бойцами от разработки, управления проектами, информационной безопасности и даже эксплуатации, возможно даже опытными, с медалями первой степени, но из другого рода продуктов, из "обычного софта" что ли... Эти ребята действительно уверены, что база данных всегда ответит их приложению быстро. Они с пеной у рта доказывают, что точки интеграции с elastic'ом защищать не нужно и можно делать синхронные вызовы к нему на входе в приложение. Они обижаются, когда их приложение падает. Недоумевают, почему разбираться с этим нужно вместе — ведь на тестовой все работало, а на машине у программера, вообще, все летало!!!
И только с кровью и потом приходит понимание. Поскольку кровь и пот не только их, но и мои, я задумался: а можно ли ещё на этапе грудного вскармливания подмешать этих знаний в молодые умы? Чтоб уж, если не писали сразу с учётом боевой нагрузки, то хотя бы чтоб быстро понимали, как исправлять приложение.
Как итог: новый спецкурс на Факультете информационных технологий в НГУ.
Два года, два потока.
Переписанная два раза программа, мысли переписать снова.
Трудности с лабораторными стендами. Пошёл через облака — отдал своих кровных 5 000 за время, пока настраивал, и две пары лабораторной работы в Azure.
Отказался от идеи показать для сравнения мир Microsoft с его release manager и desired state config.
С удивлением включил в программу вопросы непрерывной интеграции, а думал говорить только про поставку.
Мясо, нужно больше мяса, но нужны помощники, где взять опытных волонтеров со сбитыми костяшками.
Мучения с погружением в кух�