Да, и с такими коэффициентами Джини как в РФ или в США, 67-72% людей будут получать ниже средней. А модальная зарплата (наиболее частая) будет примерно в 2 раза ниже средней.
Обычно под постами про среднюю зарплату люди всегда забывают об этих статистических фактах.
Среднее арифметическое - это примерно 70-й перцентиль, т.к. зарплаты никогда не следуют нормальному распределению. А медиана - 50-й. Так что заменять одно на другое довольно глупо.
С перезагрузкой я развлекался при помощи shutdown и опций для отложенной перезагрузки, когда по очереди за одним компом работаешь. Ещё с автозапуском на CD тоже весёлые приколы были.
О, я примерно так же развлекался 18 лет назад. Только это был компилятор Delphi, Windows XP и программа выводила текущее системное время в диалоговом окне. А размер получился такой же, в районе 840 байт.
Вы прям в корень зрите. Зачем нужна Java c JVM, если можно взять Elixir с BEAM, и вот вам уже и Java не нужна и Docker тоже не нужен (там своих фич хватает для горизонтального масштабирования и отказоустойчивости)
Вообще тестирование - это больше про склад характера. Технических навыков там зачастую требуется не так уж много. Поэтому если усидчивость, въедливость и внимательность вам свойственны, то работу в тестировании вы найдёте.
пример выпускника Практикума Влада, который пришел в QTIM в 2022 году джуном, за несколько недель самостоятельно перешёл с фреймворка React на Nuxt и Vue.js, на которых пишут в компании, и за полгода вырос до ведущего разработчика.
Сколько лет он программировал до Яндекс Практикума? Или тупо враньё?
Я не вангую. Я просто внимательно прочитал постановку. Цитата: "Нужно написать программу, которая будет проверять знание таблицы умножения второклассником". Кстати, исходя из этого, ваше предложение про числа >= 10 как раз противоречит постановке.
Бывают действительно совершенно однозначные ситуации, которые ты продумываешь наперёд, а заказчик тебе "нет, не надо! делайте как сказано в ТЗ".
Ну, с заказчиком это всё надо обсуждать конечно. Эта стадия разработки называется бизнес-анализ.
Ну во-первых, и что с того что оно будет генерировать дубликаты?
Вы проверите за N итераций меньше примеров. А значит точность итоговой оценки знаний будет ниже. Можно, конечно, заставить бедных второклассников отрешать больше итераций, но это как-то негуманно. Зачем детям лишний стресс создавать из-за того, что кто-то поленился на программном уровне убрать дубли?
Во-вторых, решение автора отнюдь не наивное. Понимание того, что здесь уместнее использовать операцию умножения, а не деления - не самое очевидное.
Ну хз, всё конечно субъективно. На мой взгляд, это первое что приходит в голову и это супер очевидное решение. Плюс, как уже в комментариях писали, помимо дублей, это решение имеет ещё и проблемы с равномерностью распределения. Т.е. да, решение условно рабочее (т.к. формально удовлетворяет ТЗ), но оно халтурное с точки зрения профессиональной разработки.
Хотя допускаю, что для школьников это всё не столь очевидно. Но на то они и школьники, а не программисты.
Упс, действительно перепутал. У вас просто такой же агрессивный стиль комментариев.
очень интересно, что вы подразумеваете под "production-ready"?
В данном случае, я имею в виду насколько реализация справляется с тем, что нужно на практике. Хоть постановка задачи и конченая, но в ней всё же указано, что мы пишем программу, которая должна тестировать школьников на знание таблицы умножения. Т.е., условно говоря, выдавать 20 примеров и считать сколько из них решено правильно. Очевидно, что для целей такого тестирования необходимо избегать дублирующих примеров, чтобы охватить более существенную часть таблицы.
Решение описанное автором как правильное является наивным, потому что оно примерно в 25% случаев будет генерировать дубликаты примеров. В итоге у вас будет всего 15 из 20 уникальных вопросов. Что ни в какие ворота не годится для объективной проверки знаний.
а что значит "слишком наивный"? это что ещё за практики?))
Странно, что вы как практикующий программист не слышали этот термин. Загуглите "naive algorithm". Оно означает наиболее очевидный способ сделать что-либо, который не учитывает подводных камней.
в некоторых случаях, видимо, с самым натуральным "hindy code" (if a = 2...)?
Это про что вообще? Единственный if, который на всю эту программу нужен - это сравнение введенного ответа с правильным результатом.
Не нервничайте вы так. Тот вариант, который вы в статье описываете как правильный, мне первым пришёл в голову. Но он слишком наивный и не production-ready. Чтобы это понять, достаточно хотя бы минуту подумать над потенциальной бизнес-постановкой.
Просто вам, как учителю информатики, такое направление мыслей недоступно, т.к. вы не являетесь профессиональным программистом.
Разумеется, снять ограничение для множителей < 10. И после этого вам придётся переделывать всю логику.
Во-первых, это не разумеется, т.к. таблица умножения имеет строго фиксированный размер. А во-вторых, в самом снятии этого ограничения нет проблемы. Там появляются другие вопросы:
Будет ли вообще какое-то ограничение, или мы будем тестировать сверхлюдей, которые могут двадцатизначные числа в уме перемножать?
Числа должны быть произвольными или обязательно простыми и больше какого-то минимума? Уж если мы сверхлюдей собрались проверять, то задания должны быть сложными, так ведь?
Можно подумать, они первые это придумали. Всякие стратегии доверительного управления и хедж-фонды давным давно так делают. Там, правда, обычно 2-3% от портфеля безусловно + 20% от прибыли.
Если добавить к условиям требование, чтобы задания не повторялись в рамках одного прогона программы (что весьма логичное требование для программы, которая тестирует знание таблицы умножения), то вариант иметь заранее сгенерированную структуру данных становится очень даже уместен. Это может быть хеш-таблица, где ключ - произведение, а значение - массив из множителей. В языках с поддержкой метапрограммирования, такое можно на этапе компиляции нагенерить. В остальных - захардкодить.
Сравните: вариант 1: выбираете одно рандомный ключ, показываете пример и затем убираете это этот ключ из хеш-таблицы (повторяете нужное кол-во раз)
вариант 2: генерируете множители, и начинаете сохранять их произведения в массив и на каждой итерации проверяете, что псевдослучайное произведение не входит в массив, а если входит - перегенерируете пока не сгенерируете нужное.
Да, и с такими коэффициентами Джини как в РФ или в США, 67-72% людей будут получать ниже средней. А модальная зарплата (наиболее частая) будет примерно в 2 раза ниже средней.
Обычно под постами про среднюю зарплату люди всегда забывают об этих статистических фактах.
Среднее арифметическое - это примерно 70-й перцентиль, т.к. зарплаты никогда не следуют нормальному распределению. А медиана - 50-й. Так что заменять одно на другое довольно глупо.
Ну, COM с PE не совсем честно сравнивать)
С перезагрузкой я развлекался при помощи shutdown и опций для отложенной перезагрузки, когда по очереди за одним компом работаешь. Ещё с автозапуском на CD тоже весёлые приколы были.
О, я примерно так же развлекался 18 лет назад. Только это был компилятор Delphi, Windows XP и программа выводила текущее системное время в диалоговом окне. А размер получился такой же, в районе 840 байт.
Вы прям в корень зрите. Зачем нужна Java c JVM, если можно взять Elixir с BEAM, и вот вам уже и Java не нужна и Docker тоже не нужен (там своих фич хватает для горизонтального масштабирования и отказоустойчивости)
Тогда замените на Elixir: https://nerves-project.org/
Кода получится раза в 2 меньше, чем на питоне)
Годная статья. Будет полезна новичкам.
Вообще тестирование - это больше про склад характера. Технических навыков там зачастую требуется не так уж много. Поэтому если усидчивость, въедливость и внимательность вам свойственны, то работу в тестировании вы найдёте.
Сколько лет он программировал до Яндекс Практикума? Или тупо враньё?
В целом, вы порядок правильно определили, но что за странный вариант интегрирования. Особенно, трюк с переходом от 1061 к 1.6 * 10^3 хорош :)
И почему просто не вычесть объём Земли из объёма большего шара?
Кому лень считать, 1.374 * 10^21 м^3 там получается
Я не вангую. Я просто внимательно прочитал постановку. Цитата: "Нужно написать программу, которая будет проверять знание таблицы умножения второклассником".
Кстати, исходя из этого, ваше предложение про числа >= 10 как раз противоречит постановке.
Ну, с заказчиком это всё надо обсуждать конечно. Эта стадия разработки называется бизнес-анализ.
Вы проверите за N итераций меньше примеров. А значит точность итоговой оценки знаний будет ниже. Можно, конечно, заставить бедных второклассников отрешать больше итераций, но это как-то негуманно. Зачем детям лишний стресс создавать из-за того, что кто-то поленился на программном уровне убрать дубли?
Ну хз, всё конечно субъективно. На мой взгляд, это первое что приходит в голову и это супер очевидное решение. Плюс, как уже в комментариях писали, помимо дублей, это решение имеет ещё и проблемы с равномерностью распределения. Т.е. да, решение условно рабочее (т.к. формально удовлетворяет ТЗ), но оно халтурное с точки зрения профессиональной разработки.
Хотя допускаю, что для школьников это всё не столь очевидно. Но на то они и школьники, а не программисты.
Упс, действительно перепутал. У вас просто такой же агрессивный стиль комментариев.
В данном случае, я имею в виду насколько реализация справляется с тем, что нужно на практике. Хоть постановка задачи и конченая, но в ней всё же указано, что мы пишем программу, которая должна тестировать школьников на знание таблицы умножения. Т.е., условно говоря, выдавать 20 примеров и считать сколько из них решено правильно. Очевидно, что для целей такого тестирования необходимо избегать дублирующих примеров, чтобы охватить более существенную часть таблицы.
Решение описанное автором как правильное является наивным, потому что оно примерно в 25% случаев будет генерировать дубликаты примеров. В итоге у вас будет всего 15 из 20 уникальных вопросов. Что ни в какие ворота не годится для объективной проверки знаний.
Странно, что вы как практикующий программист не слышали этот термин. Загуглите "naive algorithm". Оно означает наиболее очевидный способ сделать что-либо, который не учитывает подводных камней.
Это про что вообще? Единственный if, который на всю эту программу нужен - это сравнение введенного ответа с правильным результатом.
Не нервничайте вы так. Тот вариант, который вы в статье описываете как правильный, мне первым пришёл в голову. Но он слишком наивный и не production-ready. Чтобы это понять, достаточно хотя бы минуту подумать над потенциальной бизнес-постановкой.
Просто вам, как учителю информатики, такое направление мыслей недоступно, т.к. вы не являетесь профессиональным программистом.
Во-первых, это не разумеется, т.к. таблица умножения имеет строго фиксированный размер. А во-вторых, в самом снятии этого ограничения нет проблемы. Там появляются другие вопросы:
Будет ли вообще какое-то ограничение, или мы будем тестировать сверхлюдей, которые могут двадцатизначные числа в уме перемножать?
Числа должны быть произвольными или обязательно простыми и больше какого-то минимума? Уж если мы сверхлюдей собрались проверять, то задания должны быть сложными, так ведь?
Кхм. У меня в начале нулевых были уроки информатики на Бейсик-Агат. Слышали про советский аналог Apple II?
К 11-му классу правда завезли PC, так что к урокам информатики добавилось ещё рисование в Paint ?
Или не конвертируется. Смотря как себя проявил. Плюс стажерам обычно вообще не платят, ну или что-то типа стипендии 5-10 т.р.
Можно подумать, они первые это придумали. Всякие стратегии доверительного управления и хедж-фонды давным давно так делают. Там, правда, обычно 2-3% от портфеля безусловно + 20% от прибыли.
Более известный, как нуб)
А относительно работы есть ещё должность "стажёр". Раньше на неё набирали людей с 2-3 годами опыта в программировании для себя.
А мне понравился термин "псевдо-обучение". Он прям так точно описывает все эти онлайн-курсы.
Если добавить к условиям требование, чтобы задания не повторялись в рамках одного прогона программы (что весьма логичное требование для программы, которая тестирует знание таблицы умножения), то вариант иметь заранее сгенерированную структуру данных становится очень даже уместен. Это может быть хеш-таблица, где ключ - произведение, а значение - массив из множителей. В языках с поддержкой метапрограммирования, такое можно на этапе компиляции нагенерить. В остальных - захардкодить.
Сравните:
вариант 1: выбираете одно рандомный ключ, показываете пример и затем убираете это этот ключ из хеш-таблицы (повторяете нужное кол-во раз)
вариант 2: генерируете множители, и начинаете сохранять их произведения в массив и на каждой итерации проверяете, что псевдослучайное произведение не входит в массив, а если входит - перегенерируете пока не сгенерируете нужное.
Второй вариант явно сложнее.
Нет, C++ тоже не особо подходит на роль первого языка.
Я вот тут перечислял из какого списка языков, на мой взгляд, стоит выбирать для начала.
Ну, так то любой может. Более интересный вопрос, сколько вы на этом бабок освоили?