Как сказал Д.И. Медведев "Учитель - это призвание". Если вам нравится обучать людей - могли бы сходить поучить.
Я работал и в ВУЗе и на коммерческих курсах.
В ВУЗе нужно было днём, очень неохотно по вечерам могли дать часы. Больше всего напрягала бумажная волокита - а не маленькая зарплата. Хочется обучить нужному студентов, а не чтобы по бумагам было всё хорошо и только по ним. Сейчас не могу работать днём в ВУЗе - т.к. основная работа есть и не отпускают.
На коммерческих курсах нет бумажной волокиты, платят выше чем в ВУЗе, занятия по вечерам и по выходным - не нужно отпрашиваться с работы.
Главная мысль такая: преподавать должно нравиться и должно получаться, но не нужно вставлять палки в колёса преподавателям.
Вот это анализ! В принципе что понял для себя - если начал вести бизнес, то нужно именно его вести, а не пускать всё на самотёк
Нужно предварительно потратить ресурсы на подготовку к бизнесу: изучить рынок сбыта, посмотреть на конкурентов, посмотреть на каналы сбыта, определить свою целевую аудиторию, провести анализ доходов и расходов в самых радужных мечтах и в самых худших реалиях и т.п.
Нужно не забывать про свою ЦА: постоянно держать с ней контакт, работать на свой имидж, а не просто продавать.
Нужно искать пути оптимизации процессов - договариваться с поставщиками или с теми, кто может вашу продукцию сбывать/использовать. Нужно общаться.
Не все варианты бизнеса могут принести большой доход.
Это тяжело: возможно придётся себя сильно поменять.
Спасибо за обзор. Попробую использовать в обучении со студентами. Только вот ссылку в статье не нашёл на ресурс. Вроде вот эта - https://tryrabbitmq.com/
Может быть не совсем так. Желающих преподавать много, а вот желающих работать в ВУЗе - не много. Сам процесс преподавания и работа преподавателем в ВУЗе - сильно разняться. Если сделают определённые послабления для работающих преподавателей - то и без обязаловки увеличится число желающих работать в ВУЗе.
Какие послабления (моё субъективное мнение):
Полное отсутствие "бумажной волокиты": разработка рабочих программ и т.п. Для этих целей хорошо бы в ВУЗе иметь специалиста, который совместно с преподавателями будет все эти "бумажки" правильно оформлять.
Понимание со стороны руководства компании: выделение времени на проведение занятий в ВУЗе в основное рабочее время.
Т. е. того самого "неправильно написанного" кода ещё нет.
Нет, уже есть неправильно написанный код - так он содержит потенциальную угрозу. И нужно в таком случаен не аннотации писать, а переделывать его! Разработчик А понял, до начала использования своего кода, что он "плохой" и не стал исправлять, а просто пометил что код плохой. Причём пометил в отдельном месте, а не в коде оставил отметку.
Можете другой пример привести? На этом примере мы что-то никак не можем прийти к согласию )))
Ещё раз уточню: смысл аннотаций не в том, чтобы добавлять их после обнаружения проблемы, а в том, чтобы обнаружить ошибку сразу, как только она будет допущена, потому что для соответствующего метода уже существует аннотация.
Но аннотацию пишу я сам и я сам понимаю, что тут может быть проблема. Следовательно, я сам могу переделать код на этапе его написания, когда осознал что тут может быть ошибка.
В статье не указано, что разработчик знает о том, что код написан неправильно. Допустим, код был размечен одним разработчиком, знающим об уязвимостях, после чего над проектом начал работать другой, который о них не знает. Он вполне мог написать код, аналогичный тому, что приведён в примере.
Если разработчик не знает, что код написан неправильно - то как тогда он сделает аннотирование для PVS? Ведь даже в вашем синтетическом примере в аннотации явно указано что может быть SQL-инъекция. Следовательно его можно тут же исправить. Если этого сделать нельзя - то можно оставить комментарий к коду. Ибо комментарий к коду быстрее прочитается, чем оповещение PVS.
Повторюсь ещё раз. Мне из статьи не совсем понятно как применять аннотирование для PVS. То, что пример синтетический - это плохо. Лучше бы показали на реальном примере (как у вас на стойках на конференциях сделано: карточки с ошибками, попробуй их там найди). Сама идея аннотирования узких мест - мне кажется странной или я не понял её смысла.
Ещё раз уточню: смысл аннотаций не в том, чтобы добавлять их после обнаружения проблемы, а в том, чтобы обнаружить ошибку сразу, как только она будет допущена, потому что для соответствующего метода уже существует аннотация.
Но аннотацию пишу я сам и я сам понимаю, что тут может быть проблема. Следовательно, я сам могу переделать код на этапе его написания, когда осознал что тут может быть ошибка.
В статье не указано, что разработчик знает о том, что код написан неправильно. Допустим, код был размечен одним разработчиком, знающим об уязвимостях, после чего над проектом начал работать другой, который о них не знает. Он вполне мог написать код, аналогичный тому, что приведён в примере.
Если разработчик не знает, что код написан неправильно - то как тогда он сделает аннотирование для PVS? Ведь даже в вашем синтетическом примере в аннотации явно указано что может быть SQL-инъекция. Следовательно его можно тут же исправить. Если этого сделать нельзя - то можно оставить комментарий к коду. Ибо комментарий к коду быстрее прочитается, чем оповещение PVS.
Повторюсь ещё раз. Мне из статьи не совсем понятно как применять аннотирование для PVS. То, что пример синтетический - это плохо. Лучше бы показали на реальном примере (как у вас на стойках на конференциях сделано: карточки с ошибками, попробуй их там найди). Сама идея аннотирования узких мест - мне кажется странной или я не понял её смысла.
Очень жаль, что не планируете пока поддержки C#. Вот прям не хватает нормальной российской IDE для него.
Не знал про такое деление.
Есть ещё Uno Platform с таким же функционалом.
Либо я не понимаю о чём вы говорите, либо мы об одном и том же, но разными словами.
Либо я не понимаю о чём вы говорите, либо мы об одном и том же, но разными словами.
Ну это тогда самообучении какое-то, а не обучение в ВУЗе...
Как сейчас с этим - не подскажу. Но я в единичных ВУЗах такое вижу.
Хотел однажды попробовать внедрить в учебный процесс работу с GitFlic - что-то куда-то нужно было сходить, а как и что - никто не может объяснить...
Такой формат считаю неправильным. Только живое общение со студентами, по большей части практические примеры и побольше часов.
Я работал и в ВУЗе и на коммерческих курсах.
В ВУЗе нужно было днём, очень неохотно по вечерам могли дать часы. Больше всего напрягала бумажная волокита - а не маленькая зарплата. Хочется обучить нужному студентов, а не чтобы по бумагам было всё хорошо и только по ним. Сейчас не могу работать днём в ВУЗе - т.к. основная работа есть и не отпускают.
На коммерческих курсах нет бумажной волокиты, платят выше чем в ВУЗе, занятия по вечерам и по выходным - не нужно отпрашиваться с работы.
Главная мысль такая: преподавать должно нравиться и должно получаться, но не нужно вставлять палки в колёса преподавателям.
Точно. Только в тексте у вас ссылка на ресурс как текст - поэтому и пропустил её.
Вот это анализ!
В принципе что понял для себя - если начал вести бизнес, то нужно именно его вести, а не пускать всё на самотёк
Нужно предварительно потратить ресурсы на подготовку к бизнесу: изучить рынок сбыта, посмотреть на конкурентов, посмотреть на каналы сбыта, определить свою целевую аудиторию, провести анализ доходов и расходов в самых радужных мечтах и в самых худших реалиях и т.п.
Нужно не забывать про свою ЦА: постоянно держать с ней контакт, работать на свой имидж, а не просто продавать.
Нужно искать пути оптимизации процессов - договариваться с поставщиками или с теми, кто может вашу продукцию сбывать/использовать. Нужно общаться.
Не все варианты бизнеса могут принести большой доход.
Это тяжело: возможно придётся себя сильно поменять.
Спасибо за обзор. Попробую использовать в обучении со студентами.
Только вот ссылку в статье не нашёл на ресурс. Вроде вот эта - https://tryrabbitmq.com/
Может быть не совсем так. Желающих преподавать много, а вот желающих работать в ВУЗе - не много.
Сам процесс преподавания и работа преподавателем в ВУЗе - сильно разняться.
Если сделают определённые послабления для работающих преподавателей - то и без обязаловки увеличится число желающих работать в ВУЗе.
Какие послабления (моё субъективное мнение):
Полное отсутствие "бумажной волокиты": разработка рабочих программ и т.п. Для этих целей хорошо бы в ВУЗе иметь специалиста, который совместно с преподавателями будет все эти "бумажки" правильно оформлять.
Понимание со стороны руководства компании: выделение времени на проведение занятий в ВУЗе в основное рабочее время.
Странное, на мой взгляд, понимание у них учёбы.
Долгоиграющая
Разбор примеров - отличный. Правда я пропустил длинное вступление. А вот с примерами багов и их объяснением - было интересно.
Спасибо! Этот вариант я понял.
Нет, уже есть неправильно написанный код - так он содержит потенциальную угрозу. И нужно в таком случаен не аннотации писать, а переделывать его!
Разработчик А понял, до начала использования своего кода, что он "плохой" и не стал исправлять, а просто пометил что код плохой. Причём пометил в отдельном месте, а не в коде оставил отметку.
Можете другой пример привести? На этом примере мы что-то никак не можем прийти к согласию )))
Но аннотацию пишу я сам и я сам понимаю, что тут может быть проблема. Следовательно, я сам могу переделать код на этапе его написания, когда осознал что тут может быть ошибка.
Если разработчик не знает, что код написан неправильно - то как тогда он сделает аннотирование для PVS? Ведь даже в вашем синтетическом примере в аннотации явно указано что может быть SQL-инъекция. Следовательно его можно тут же исправить. Если этого сделать нельзя - то можно оставить комментарий к коду. Ибо комментарий к коду быстрее прочитается, чем оповещение PVS.
Повторюсь ещё раз. Мне из статьи не совсем понятно как применять аннотирование для PVS. То, что пример синтетический - это плохо. Лучше бы показали на реальном примере (как у вас на стойках на конференциях сделано: карточки с ошибками, попробуй их там найди).
Сама идея аннотирования узких мест - мне кажется странной или я не понял её смысла.
Но аннотацию пишу я сам и я сам понимаю, что тут может быть проблема. Следовательно, я сам могу переделать код на этапе его написания, когда осознал что тут может быть ошибка.
Если разработчик не знает, что код написан неправильно - то как тогда он сделает аннотирование для PVS? Ведь даже в вашем синтетическом примере в аннотации явно указано что может быть SQL-инъекция. Следовательно его можно тут же исправить. Если этого сделать нельзя - то можно оставить комментарий к коду. Ибо комментарий к коду быстрее прочитается, чем оповещение PVS.
Повторюсь ещё раз. Мне из статьи не совсем понятно как применять аннотирование для PVS. То, что пример синтетический - это плохо. Лучше бы показали на реальном примере (как у вас на стойках на конференциях сделано: карточки с ошибками, попробуй их там найди).
Сама идея аннотирования узких мест - мне кажется странной или я не понял её смысла.