Я веду индивидуальные курсы параллельно с работой и обеспечиваю людей уверенными знаниями для устройства в IT-компании. Метрику трудоустройства я не собираю, потому что не могу выделить на это время.
2200 часов на 50 учеников, получается в среднем по 44 часа на одного.
Судя по материалам на github, за это время ученик успеет пройти введение в программирование, базовый sql и webforms.
В IT компании после этого возможно и возьмут, но не IT-специалистом.
Для более-менее нормальной подготовки нужно раз в 10 больше времени.
Т.е. бюджет в районе 600 тыс. руб.
Если в youtube искать не просто видео, а именно курсы (со ссылками на конспекты лекций, литературу и задания), то в чем преимущества очных вечерних курсов вообще непонятно.
Да, качество многих видео очень низкое.
Но если авторы плохих видео-курсов отправятся в онлайн, качество вряд ли будет выше.
А это накладные расходы, т.к. CI фактически нет.
И расписание мержей веток перед релизом, т.к. всем нужно успеть…
Я не говорю, что это однозначно плохо — сам такую модель внедрял. Но поддерживать ее трудозатратно, т.е. теоретически есть резерв повышения эффективности. Но практического решения пока не нашел.
Каждая модель ветвления подходит для соответствующих команд, культур и условий. Сторонникам CD подходит модель, максимально упрощающая процесс. Кто-то обожает разработку на основе trunk'ов (trunk-based development) и переключатели функциональности (feature flags).
В CD патчи не нужны — там новые релизы.
И в зрелой CD организации каждый коммит в транк обеспечивается ту же предсказуемость и стабильность, что мерж фиче-ветки в Вашем случае.
В целом, у статьи только название провокационное, а так она вполне себе описывает зону применимости git flow:
Если ваша компания придерживается месячного или квартального цикла выпуска ПО, а команда параллельно работает над несколькими релизами, то Git-flow может стать неплохим выбором.
И заметим, никаких альтернатив в этом сценарии не предлагается.
А было бы интересно…
Александр, не нужно писать новый язык, лучше найдите любую квалифицированную работу, изучайте то, что нужно рынку, и заочно получайте высшее образование.
Автор и написал транслятор из cine в C.
Цитата из комментария
Программы на cine распространяются в виде fpkg пакетов, которые можно даже текстовым редактором открыть и увидеть Си код. А на машине конечного пользователя, программа fei скомпилирует Си код в бинарник.
Только компилирует не fei, а clang, который вызывается из fei.
И кросс-платформенность страдает именно при трансляции (захаркоженные Linux пути, использование dirent.h и специфичных вызовов для файловых операций)
В принципе, я собрал cine и fei под Windows. fei уже генерит helloworld, как раз дошел до вызова ciine при fei build
Т.ч. имею некое представление о том, как работает fei.
Грустная история…
«Стратегия без тактики — это самый медленный путь к победе. Тактика без стратегии — это просто суета перед поражением.“ — Сунь Цзы.
Александр, я бы посоветовал миссию с ЯП считать выполненной, поставить жизненную цель и идти к ней с тем же упорством.
Чем больше времени уходит, тем меньше шансов устроиться на любую квалифицированную работу.
Даже если вы доведете свой проект до совершенства, ни одна вменяемая организация не предложит вам работу программистом.
Я не HR, но отсею по резюме. И не из-за отсутствия высшего образования, а из-за недостатка требуемых компетенций для решения производственных задач. Даже если дойдете до этапа технического интервью, то шансы прости его успешно не очень большие.
Несколько замечаний по самому проекту.
То, что оно транслируется в С, не делает программы заведомо эффективными.
Скажем, тривиальный hello world транслируется в 30 КБ кода на С (вместо 60 байт). И результирующий бинарник получается в 3 раза больше.
Бенчмарк идиотский, конечно, но других пока нет.
standart-test генерирует код, который не собирается (или собирается с 1799 варнингами после магии с ключами компиляции). Причем, размер С файла уже под 2.5 МБ. Оно точно будет быстро?
В чем магия пакаджей и fei я просто не понял. Почему бы просто не генерить С и make файлы для clang, зачем это в один файл сливать? По крайней мере, на данном этапе?
Баг: если в программе только инлайн С, то она не собирается (выше пример про printf), если потом добавить вызов printLn, то собирается.
Совет про сравнение с NumPy — очень правильный. Никто же не требует, чтобы оно сходу было быстрее, но база для сравнения должна быть?
Статья содержит только основные идеи создания автоматических тестов в Agile команде.
Извините, не нашел, по большей части вижу только обрывки фраз. Можете привести несколько примеров идей из статьи?
Я понимаю, что тема горячая, но за два десятка лет с начала использования Agile в разработке ПО от создателей курсов ждешь гораздо более зрелого материала.
Надеюсь, что читатели статьи сделают правильные выводы о качестве курсов.
Какую бы из Agile-методологий вы не выбрали, вы можете качественно реализовать ее с помощью платформы для управления проектами Hygger.io.
Если у аналитиков платформы такой же поверхностный уровень понимания scrum и kanban, как оно изложено в статье, то я сильно сомневаюсь в качестве реализации.
Можно привести хоть какие-нибудь преимущества по сравнению с JIRA + Agile add-on?
А вот что меня действительно немного беспокоит, это возросшее число абсолютно нетехнических пространных статей, собирающих кучу лайков и поднимающих хайп.
Не стесняйтесь минусовать бессодержательные статьи — и будет нам счастье :-)
Для меня загадка, зачем 45 человек добавили данную статью в закладки.
Для специалистов в какой области она полезна?
Извиняюсь, еще раз прошелся по ссылкам и не нашел каких-то результатов использования survival analysis для предсказания увольнения сотрудников.
Посмотрел на Watson Analytics Use Case for HR: Retaining valuable employees, там ставилась совсем другая задача — выделить драйверы аттришина:
one of my tasks is to determine which factors keep employees at my company and which prompt others to leave
Автор выделил 10 значимых факторов.
У Вас же совсем другая формулировка:
создание модели, прогнозирующей уход сотрудников с заданной точностью (не менее 75-80%)
Про survival analysis люди, касающиеся темы HR даже не слышали. А применение его более оправданно, чем параметризованная классификация.
А этому утверждению есть какое-то подтверждение?
Чтобы я сказал по графику (на уровне гипотез):
30-32 месяца назад в компании были массовые сокращения (или народ начал массово перетекать к конкурентам);
последние 10 месяцев в компании идут сокращения (либо все активно перетекают к конкурентам);
я вовсе не уверен, что при принятии решений о сокращении главным фактором являются переработки (скорее должность или специальность).
Применим ли в этих условиях survival analysis? У пенсионеров гораздо меньше возможностей повлиять на ситуацию, чем у работников или руководителей конкретного предприятия. Отдельная компания гораздо менее устойчива, чем экономика государства, динамика гораздо выше.
Может стоит обратить внимание на подготовку данных для анализа, а не выбор модели?
Рано или поздно любая организация начинает выдавать в качестве продукта свою организационную диаграмму, и Windows не исключение. У open source нет такой проблемы.
Интересно, как закон Конвея проявляется в крупных open source сообществах. Есть у кого-нибудь такой опыт?
На самом деле, в статье очень много анти-паттернов управления продуктами и проектами.
Просто учебник «как делать не надо». Я лишь подчеркнул некоторые из них.
В моем случае это было порядка 10 лет назад.
Приняли бы мы сегодня иные решения? Да. Зрение при взгляде в прошлое становится стопроцентным. Тогда мы не знали того, что знаем сейчас.
Причем, для некоторых проблем я не вижу решения даже сейчас.
Например, разработка новой версии платформы и новой версии продукта на базе этой платформы в одном релизном цикле.
В теории, надо бы сначала стабилизировать платформу, но на практике она устареет к следующему релизному циклу. Да и многие проблемы начнут вылазить только во время интеграции.
Т.ч. эволюция выглядит предпочтительнее революций в плане предсказуемости результатов, но часто проигрывает в продуктивности.
И за что минусуете человека? Имеете опыт безболезненного переписывания драйверов под Vista? В статье же не зря упоминаются судебные процессы — очень похоже было на зачистку поля под Security Essentials.
2200 часов на 50 учеников, получается в среднем по 44 часа на одного.
Судя по материалам на github, за это время ученик успеет пройти введение в программирование, базовый sql и webforms.
В IT компании после этого возможно и возьмут, но не IT-специалистом.
Для более-менее нормальной подготовки нужно раз в 10 больше времени.
Т.е. бюджет в районе 600 тыс. руб.
Если в youtube искать не просто видео, а именно курсы (со ссылками на конспекты лекций, литературу и задания), то в чем преимущества очных вечерних курсов вообще непонятно.
Да, качество многих видео очень низкое.
Но если авторы плохих видео-курсов отправятся в онлайн, качество вряд ли будет выше.
Т.е. хотфиксы не тестируются, сразу в прод?
Не задавались вопросом, откуда берется потребность в хотфиксах? Их же не должно быть в CD?
И расписание мержей веток перед релизом, т.к. всем нужно успеть…
Я не говорю, что это однозначно плохо — сам такую модель внедрял. Но поддерживать ее трудозатратно, т.е. теоретически есть резерв повышения эффективности. Но практического решения пока не нашел.
В CD патчи не нужны — там новые релизы.
И в зрелой CD организации каждый коммит в транк обеспечивается ту же предсказуемость и стабильность, что мерж фиче-ветки в Вашем случае.
В целом, у статьи только название провокационное, а так она вполне себе описывает зону применимости git flow:
И заметим, никаких альтернатив в этом сценарии не предлагается.
А было бы интересно…
cine-lang.blogspot.com/2020/02/blog-post.html
Здесь уже была ссылка на compiler.su
Советую обратить внимание на страничку compiler.su/entuziasty-razrabotchiki-kompilyatorov-i-ikh-proekty.php
Там очень часто встречается Статус: проект не развивается.
А из успешных проектов могу назвать только Kotlin
Цитата из комментария
Только компилирует не fei, а clang, который вызывается из fei.
И кросс-платформенность страдает именно при трансляции (захаркоженные Linux пути, использование dirent.h и специфичных вызовов для файловых операций)
В принципе, я собрал cine и fei под Windows. fei уже генерит helloworld, как раз дошел до вызова ciine при fei build
Т.ч. имею некое представление о том, как работает fei.
stackoverflow.com/questions/14408136/have-different-optimizations-plain-sse-avx-in-the-same-executable-with-c-c
software.intel.com/en-us/forums/intel-c-compiler/topic/801418
примерно этим и пользуемся для получения максимальной производительности на процессорах, которые поддерживают нужные инструкции.
«Стратегия без тактики — это самый медленный путь к победе. Тактика без стратегии — это просто суета перед поражением.“ — Сунь Цзы.
Александр, я бы посоветовал миссию с ЯП считать выполненной, поставить жизненную цель и идти к ней с тем же упорством.
Чем больше времени уходит, тем меньше шансов устроиться на любую квалифицированную работу.
Даже если вы доведете свой проект до совершенства, ни одна вменяемая организация не предложит вам работу программистом.
Я не HR, но отсею по резюме. И не из-за отсутствия высшего образования, а из-за недостатка требуемых компетенций для решения производственных задач. Даже если дойдете до этапа технического интервью, то шансы прости его успешно не очень большие.
Несколько замечаний по самому проекту.
То, что оно транслируется в С, не делает программы заведомо эффективными.
Скажем, тривиальный hello world транслируется в 30 КБ кода на С (вместо 60 байт). И результирующий бинарник получается в 3 раза больше.
Бенчмарк идиотский, конечно, но других пока нет.
standart-test генерирует код, который не собирается (или собирается с 1799 варнингами после магии с ключами компиляции). Причем, размер С файла уже под 2.5 МБ. Оно точно будет быстро?
В чем магия пакаджей и fei я просто не понял. Почему бы просто не генерить С и make файлы для clang, зачем это в один файл сливать? По крайней мере, на данном этапе?
Баг: если в программе только инлайн С, то она не собирается (выше пример про printf), если потом добавить вызов printLn, то собирается.
Совет про сравнение с NumPy — очень правильный. Никто же не требует, чтобы оно сходу было быстрее, но база для сравнения должна быть?
Извините, не нашел, по большей части вижу только обрывки фраз. Можете привести несколько примеров идей из статьи?
Я понимаю, что тема горячая, но за два десятка лет с начала использования Agile в разработке ПО от создателей курсов ждешь гораздо более зрелого материала.
Надеюсь, что читатели статьи сделают правильные выводы о качестве курсов.
Как (методология) Agile связан(а) с Тестированием
Резюмируя, лучше бы материал не просто нашли в закромах, но и подготовили к публикации.
Тема-то, и в самом деле интересная.
Если у аналитиков платформы такой же поверхностный уровень понимания scrum и kanban, как оно изложено в статье, то я сильно сомневаюсь в качестве реализации.
Можно привести хоть какие-нибудь преимущества по сравнению с JIRA + Agile add-on?
Не стесняйтесь минусовать бессодержательные статьи — и будет нам счастье :-)
Для меня загадка, зачем 45 человек добавили данную статью в закладки.
Для специалистов в какой области она полезна?
Посмотрел на Watson Analytics Use Case for HR: Retaining valuable employees, там ставилась совсем другая задача — выделить драйверы аттришина:
Автор выделил 10 значимых факторов.
У Вас же совсем другая формулировка:
.
Я просто не улавливаю связи.
А этому утверждению есть какое-то подтверждение?
Чтобы я сказал по графику (на уровне гипотез):
Применим ли в этих условиях survival analysis? У пенсионеров гораздо меньше возможностей повлиять на ситуацию, чем у работников или руководителей конкретного предприятия. Отдельная компания гораздо менее устойчива, чем экономика государства, динамика гораздо выше.
Может стоит обратить внимание на подготовку данных для анализа, а не выбор модели?
Интересно, как закон Конвея проявляется в крупных open source сообществах. Есть у кого-нибудь такой опыт?
Просто учебник «как делать не надо». Я лишь подчеркнул некоторые из них.
В моем случае это было порядка 10 лет назад.
Причем, для некоторых проблем я не вижу решения даже сейчас.
Например, разработка новой версии платформы и новой версии продукта на базе этой платформы в одном релизном цикле.
В теории, надо бы сначала стабилизировать платформу, но на практике она устареет к следующему релизному циклу. Да и многие проблемы начнут вылазить только во время интеграции.
Т.ч. эволюция выглядит предпочтительнее революций в плане предсказуемости результатов, но часто проигрывает в продуктивности.