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