Comments 34
С одной стороны, молодцы, что заморочились, с другой - не факт, что обучение подойдет другому агентству, нужны промо.
Я понимаю ваш страх, что сотрудник пройдет обучение и уйдет в другую компанию, но ученический договор это худшее, с чем я сталкивался в работе
Итоговая себестоимость нашего курса – 485 000 рублей ...
Стоимость курса для одного разработчика мы оценили в 130 тысяч рублей
Во-первых многовато заложили (даже на распиареных сайтах дешевле курсы), а во-вторых, если у вас нет лицензии на преподавательскую деятельность, то увы, ученический договор не имеет веса и будет работать, пока сотрудник это не узнает)
Мы загорелись самим курсом и его целями, только потом пришли к мысли о страховке. В себестоимость не заложены проведение занятий, проверка изученного и монтаж роликов, но, конечно, все еще раз будет взвешиваться, если решимся выпустить. Спасибо за мнение.
Какая страховка у новоиспеченного сотрудника на случай, если на нем по этому договору начнут ездить полтора года?
У нас есть четко прописанные регламенты, которые работают в обе стороны. Ну и писать могу много, но все свои гарантии сотрудник понимает еще на собесе. Есть ребята, которые в агентстве уже 5 и более лет, с самого начала.
Ваша страховка - поставить человека на деньги, его страховка - ваши регламенты? Гарантии на собесе? Так потребуйте с сотрудника гарантий на собесе с его стороны и достаточно. Почему вы так не делаете?
Даже мыслей нет в такой интерпретации. И то, и другое - добровольное письменное соглашение, обучение в целом по желанию, без принуждения. Мы изначально даем список задач еще при трудоустройстве, и не можем выйти за его пределы. У нового сотрудника сразу есть на руках гарантии, у нас - 0. Я не могу говорить за всех, но вот так, когда полностью официальная компания.
Повторяю вопрос - почему вы не ограничиваетесь честным словом соискателя при найме, если сами готовы предоставить в качестве гарантий лишь слова?
Если документы, оформленные по ТК, - лишь слова, то, получается, что и мы берем равноценное честное слово.
Вы не ответили на вопрос. Вы честное слово, что не будете ездить, вам - что не уйдут. Никаких выставлений счетов. Если у вас так замечательно работается, то какие риски?
А почему они должны начать "ездить" на разработчиках? В чем проблема, если такое случится, оплатить курс? Или не проходить этот, а купить другой, если есть желание поучиться? У Скилфэктори, Нетологии и прочих все за деньги. Вполне адекватная страховка с учетом того, что спецов в IT постоянно хантят.
Но ведь ваше обучение взаимовыгодное. Сотрудник получает знания, благодаря которым в вашей компании может вырасти в грейде (возможно), вы получаете более прокачанного сотрудника. win-win, зачем вам еще и ученический в такой ситуации? Если у вас хорошие условия, он и так не убежит)
Добрый. Да, обучение будет взаимовыгодным, если сотрудник в ближайшее время после него не получит оффер, например, от банка с зп 2Х и не уйдет молча в закат) Тут какие условия не создавай, а на рынке разработчиков всегда найдется что-то заманчивее. В целом я не открыл ничего нового своим решением с договором. И считаю его вполне логичным: прохождение этой программы - исключительно по желанию сотрудника, любые приличные курсы стоят денег. Мы лишь создали свой. Для повышения навыков у нас есть еще и абсолютно ни к чему не принуждающие мит-апы, живая библиотека и WiKi с полезными и практическими материалами, внутренние проекты-песочницы.
Интересно, какой уровень зп у вас в компании, если разработчику могут предложить х2 после прохождения внутреннего курса.
Этот пункт принес пользу и HR-отделу: выявили тех ребят, кто потенциально может уйти.
Кажется, что не совсем "исключительно по желанию сотрудника"
ЗП индивидуально: направление, грейд, оклад, оклад +kpi (смотря какой сотрудник)... Банки в целом могут себе позволить по вышке рыночной планки идти.
И ведь не одно и то же: принуждать к обучению и взять себе на заметку (что человек не стал проходить курс из-за пункта отработать 1,5 года или возместить стоимость полностью или частично)?
Интересно, где в реальном коде можно применить функцию, которая отдаёт 80000 рандомных значений. А точнее, почему вместо неё нельзя применить функцию, которая отдаёт одно рандомное значение, вызвав её 80000 раз.
Можно, но тема была "генераторы", и на основании данного "хулиганского примера" была задача минимальным изменением кода снизить потребление памяти, используя как раз генераторы.
Я так и подумал, но тут есть нюанс: генераторы не имеют отношения к потреблению памяти. Собственно, данный пример это как раз прекрасно и иллюстрирует: память экономит написание осмысленного кода (вызывать функцию не 1 раз, а 80000), а не генератор.
Я просто надеялся, что поскольку курс делают практикующие специалисты, то и примеры они будут брать из практики, а не про кошечек и собачек. Но, в общем, это было наивное ожидание: разумеется, не на всякий аспект языка можно найти пример из непосредственной практики. И всё же я бы порадовался примеру, в котором генератор используется по своему назначению: для написания более удобного кода.
Тут моя вина, я взял первое, что попалось из ДЗ для "галочки" - для вставки в текст. Благодарен за развернутый коммент, принял во внимание.
Если честно, мне ужасно не хочется выглядеть занудой. Но ещё я ужасно не люблю недопонимания :)
В общем, я имел в виду пример не для статьи, а для курса. То, что он в статье - это как раз нормально. А вот в курсе он как раз довольно слабый. Просто в реальной жизни очень редко, практически никогда нельзя заменить массив генератором. Даже для "случайных" чисел, которые чаще всего используются в примерах про "экономящие память" генераторы, скорее всего требуются не просто случайные, а случайные уникальные. То есть, уже выданные номера надо где-то хранить. И никакой экономии не будет. Не говоря уже о каких-то реальных данных.
Достоинство генератора не в том, что он "экономит память", а в том, что он может превратить цикл в массив. То есть взять любой цикл получения данных, и подать на вход функции, которая ждёт массив. И в итоге не функцию вызывать внутри цикла, а наоборот - внутрь функции передать цикл. Это часто позволяет написать более удобный или универсальный код.
А память он экономит только на таких вот вырожденных и не имеющих практического смысла примерах.
Безусловно пример о котором мы говорите синтетический и не имеет ни какого практического применения в реальной жизни. Если есть голова на плечах и опыт, то можно большинство задач решить без использования генераторов и с низким потреблением памяти. Вот только достаточно большое количество разработчиков совершенно не думает о ресурсах. Важно познакомить с генераторами и посеять зерно о том что не стоит бездумно наполнять память данными и показать к чему это может привести. Есть масса проектов, где разработчик выбирает из базы все значения и обходит их в цикле. В результате проект работает до того момента пока данные не перестанут помещаться в памяти. Далее увидев это разработчик увеличивает память. По истечению времени все повторяется, и вот сервер уже вместо 500 рублей в месяц стоит 3000 рублей, а ведь можно было просто оптимизировать код. И в данном случае можно как раз использовать генераторы для получения данных пачками.
Важно познакомить с генераторами и посеять зерно о том что не стоит бездумно наполнять память
К сожалению, вы здесь повторяете ошибку, которая, как я надеялся, подробно объяснена в комментарии выше. Давайте я попробую ещё раз. Только вы не раздражайтесь и не обижайтесь. Возможно, дело исключительно в формулировках, но в текущем виде они доносят неверную мысль.
Вышеприведённая цитата буквально вбивает в головы ваших учеников мысль о том, что генераторы экономят память, и являются чуть ли не панацеей. Повторюсь - возможно, вы не имели этого в виду. Но в такой формулировке она звучит именно так. И это тонкий момент, который надо увидеть. Смотрите. Вот вы пишете,
Есть масса проектов, где разработчик выбирает из базы все значения и обходит их в цикле.
Совершенно верно. И ниже вы сразу говорите про генераторы. При том, что
Во-первых, есть гораздо более простое и очевидное решение. Не получать из базы сразу все значения. Но вы его не упоминаете.
А во-вторых, в основе "экономии памяти" генератором лежит именно оно. Вы берёте код, который вместо получения всех значений разом, берет их по одному, и помещаете его в генератор.
Но вашей формулировкой вы сбиваете фокус с этого очевидного решения на генератор. И это представляется мне большой ошибкой.
Ответ на вопрос, как экономить память - это "не получать все значения разом, а получать и обрабатывать по одному". Очень простой, очевидный и универсальный.
А "использовать генератор" - это всего лишь частный случай применения этого подхода. К сожалению, многие студенты, воспитанные на этом утверждении, умудряются писать код, в котором внутрь генератора помещают то же самое получение всех значений разом. И их логика при этом безупречна: "Генератор же экономит память"!
Понимаете, о чём я?
Вы в своих объяснениях пропускаете ключевой момент: тот самый подход, "получать по одному, а не скопом", который на самом деле экономит память.
И не даже не упоминаете условие, при котором генератор действительно может "сэкономить память". При том, что это условие надо наоборот, подчеркивать специально: "если надо обработать большой поток данных, но функция-обработчик ожидает массив".
При такой вводной - когда функция-обработчик данных ожидает на вход массив, который она будет перебирать через foreach - решением для экономии памяти действительно является генератор. В основе которого, тем не менее, будет лежать универсальный подход "получать по одному".
Все верно. Это всего лишь частный случай применения подхода. Безусловно экономия памяти ни каким магическим способом сама по себе не появится...
К сожалению, многие студенты, воспитанные на этом утверждении, умудряются писать код, в котором внутрь генератора помещают то же самое получение всех значений разом. И их логика при этом безупречна: "Генератор же экономит память"!
С таким к счастью не встречался, звучит ужасно, но это один из моментов для переосмысления определенных трактовок и объяснений по данной теме...
С этой точки зрения для приближения к реальности задачу стоило бы развернуть наоборот: функция не отдаёт массив, а принимает. Скажем, у нас есть уже существующая функция, которая принимает на вход массив. Но при большом объеме обрабатываемых данных тратится много памяти. При этом данные поступают из какого-либо потока - файла или например базы данных. Вот в этом случае в функцию имеет смысл передавать вместо массива генератор.
В итоге нам не придётся для экономии памяти переписывать код, обрабатывающий массив, помещая его в функцию, которая вызывается внутри цикла получения данных - как это пришлось бы делать до появления генераторов. А всего лишь надо будет немного переписать код, получающий эти данные - не в массив, а в генератор.
В презентациях по теме генераторов есть реальные примеры кода которые можно применить на практике. Например, обработка большого объема данных из базы пачками (чанками, если угодно). Скрин который Вы увидели это лишь мимолетная проверочная работа, что информация не прошла мимо ушей. Она нужна была как сигнал к тому, что мы можем перейти к Coroutine, пояснение по которым без понимания генераторов бессмысленно на мой взгляд...
Брать деньги за ВНУТРЕННЕЕ обучение для действующих сотрудников компании - большей дичи трудно придумать. Никто так не заинтересован в повышении качества разработки, как сам бизнес и все линейные руководители. Я понимаю если бы вы устраивали буткэмп для студентов и брали к себе по завершению курса, но ваш подход мне чужд.
Любые агентства мне представляются галерами, которым главное продать разработчика заказчику, а дальше уже это проблема разработчика и его прямого руководителя. Но все же за репутацией то надо хоть как-то следить, чтобы недоученный джун не положил прод тяжёлыми запросами?
Касательно ценника - никому не нужны пхп курсы от ноунейм конторы за такие деньги. Посмотрите OTUS который уважают в php-комьюнити, посмотрите других конкурентов. Зачем идти к вам за дорогой и необкатанной компиляцией из чужих курсов?
Извините, а можно уточнить, откуда такой пиетет перед Отусом? Есть какой-то источник объективной оценки? Так-то их курсы я не видел, но если судить по их статьям на Хабре, то там всё очень плохо.
Не могу дать комментариев касательно пиетета. Я пощупал их курс "PHP разработчик" из одного зеленого приложения, мне понравился материал. Думал о покупке, но в итоге приобрел Symfony. На php я все же почти пять лет пишу, и большую часть из первого курса наверняка знаю. А вот Symfony меня давно интересовал, но все не доходили руки. Материал хорошо структурирован, показывают некоторые тонкости неочевидные, по домашкам дают подробную обратную связь, в чате можно спрашивать сложные вещи, и на них скорее всего даже ответят, если это не совсем оффтоп.
Плюс у них есть лицензия, так что можно получить сертификат (пофиг) и налоговый вычет (приятно). Насчет остальных курсов ничего не скажу, может хорошие, может плохие. А вот Каморин клевый дядька и явно сильный разраб, кто с ним лично знаком, все хорошо отзывались, так что рекомендую.
Добрый. Недоученных джунов и не продашь. Да и, действительно, дорога репутация. А вот про сам курс - интересная оценка, т.к. "чужих курсов" никто не использовал. По ценнику, правда, надо думать. Но за этим и выпустил статью и поэтому честно благодарю за мнение.
Итоговая себестоимость нашего курса – 485 000 рублей. Она рассчитана из часов руководителей, которые затрачены на подготовку.
Я правильно понимаю что это вся себестоимость всего курса, - т.е. все затраты (учтенные) понесенные на его изготовление ?
Просто, у меня сложилось такое впечатление из прочтения формулировки.
Что указанная цена, - это не та цена которую вы планировали брать с каждого возможного обучающегося! Так ли?
Добрый день. Это сухой подсчет в часах (средний показатель), затраченных на создание фактуры курса. Без времени на его ведение, проверку ДЗ и обработку в видеоформат. В условно "тестовом" режиме стоимость за курс мы обозначили, посмотрев на рынок. Вопрос о том, сколько будет стоить обучение при выпуске в продакшн, еще открыт. Как и то, выпускать ли его вообще. Вот, собираю мнения)
Сделали свой обучающий курс для разработчиков. Выпускать или нет?