Упс, действительно перепутал. У вас просто такой же агрессивный стиль комментариев.
очень интересно, что вы подразумеваете под "production-ready"?
В данном случае, я имею в виду насколько реализация справляется с тем, что нужно на практике. Хоть постановка задачи и конченая, но в ней всё же указано, что мы пишем программу, которая должна тестировать школьников на знание таблицы умножения. Т.е., условно говоря, выдавать 20 примеров и считать сколько из них решено правильно. Очевидно, что для целей такого тестирования необходимо избегать дублирующих примеров, чтобы охватить более существенную часть таблицы.
Решение описанное автором как правильное является наивным, потому что оно примерно в 25% случаев будет генерировать дубликаты примеров. В итоге у вас будет всего 15 из 20 уникальных вопросов. Что ни в какие ворота не годится для объективной проверки знаний.
а что значит "слишком наивный"? это что ещё за практики?))
Странно, что вы как практикующий программист не слышали этот термин. Загуглите "naive algorithm". Оно означает наиболее очевидный способ сделать что-либо, который не учитывает подводных камней.
в некоторых случаях, видимо, с самым натуральным "hindy code" (if a = 2...)?
Это про что вообще? Единственный if, который на всю эту программу нужен - это сравнение введенного ответа с правильным результатом.
Не нервничайте вы так. Тот вариант, который вы в статье описываете как правильный, мне первым пришёл в голову. Но он слишком наивный и не production-ready. Чтобы это понять, достаточно хотя бы минуту подумать над потенциальной бизнес-постановкой.
Просто вам, как учителю информатики, такое направление мыслей недоступно, т.к. вы не являетесь профессиональным программистом.
Разумеется, снять ограничение для множителей < 10. И после этого вам придётся переделывать всю логику.
Во-первых, это не разумеется, т.к. таблица умножения имеет строго фиксированный размер. А во-вторых, в самом снятии этого ограничения нет проблемы. Там появляются другие вопросы:
Будет ли вообще какое-то ограничение, или мы будем тестировать сверхлюдей, которые могут двадцатизначные числа в уме перемножать?
Числа должны быть произвольными или обязательно простыми и больше какого-то минимума? Уж если мы сверхлюдей собрались проверять, то задания должны быть сложными, так ведь?
Можно подумать, они первые это придумали. Всякие стратегии доверительного управления и хедж-фонды давным давно так делают. Там, правда, обычно 2-3% от портфеля безусловно + 20% от прибыли.
Если добавить к условиям требование, чтобы задания не повторялись в рамках одного прогона программы (что весьма логичное требование для программы, которая тестирует знание таблицы умножения), то вариант иметь заранее сгенерированную структуру данных становится очень даже уместен. Это может быть хеш-таблица, где ключ - произведение, а значение - массив из множителей. В языках с поддержкой метапрограммирования, такое можно на этапе компиляции нагенерить. В остальных - захардкодить.
Сравните: вариант 1: выбираете одно рандомный ключ, показываете пример и затем убираете это этот ключ из хеш-таблицы (повторяете нужное кол-во раз)
вариант 2: генерируете множители, и начинаете сохранять их произведения в массив и на каждой итерации проверяете, что псевдослучайное произведение не входит в массив, а если входит - перегенерируете пока не сгенерируете нужное.
Разве речь шла не о том, с чего начинать обучение программированию?
Ну, как бы знание основ информатики - это пререквизит к началу обучения программированию. Т.е. знать про кодировки символов, двоичную и шестнадцатеричную системы счисления, про процессы ОС, про стандартный ввод/вывод и т.п. вполне можно до начала обучения программированию.
И, строго говоря, все эти темы не являются частью программирования, они просто используются во время программирования, ну как английский алфавит. Мы ж не говорим, что надо с изучения алфавита обучение программированию начинать?
Ну, разумеется, вы промахнулись почти со всеми додумываниями.
Там не было хайлоада.
Про soft-realtime тоже речи не шло (речь о величинах 4.5 часа vs 50 секунд).
Изначальная архитектура была плоха, и её переделка в менее критичных местах легла в техдолг.
Ну и даже в критически важных юзкейсах не удалось её полностью на адекватную переделать за эти сроки. Даже остался потенциал ускорения ещё раза в 2.
MVP или не MVP, я в любом случае за то, чтобы в начале разработки продумывать архитектуру и понимать что с ней будет при получении реального кол-ва данных, и с запасом x5.
Лично у меня немного глаз дёргается, когда я захожу на сайт, а там функционала нет и меня отправляют ставить приложение на телефон (привет некоторым службам доставки продуктов)
Как-то это по-детски обижаться на ресурс и его пользователей. Это ж позиция непризнанного гения (жертвы).
Вы выбрали интересную тему и заход был хороший. Но после "Во всех более-менее современных языках есть библиотеки для работы с денежными суммами, реализующие стандарты и скрывающие от нас адовую арифметику без потерь точности." стоило всё-таки погрузиться в детали как это работает на уровне БД и что там за адовая арифметика без потери точности. Тогда получилась бы статья для широкой аудитории, с параллельным продвижением Elixir.
Как, например, Фаулер продвигал Java своими книгами по рефакторингу и паттернам проектирования.
У вас же получилась узкоспециализованная статья, которая местами выглядит как хвастовство в стиле "во как я могу" (просто фрагменты кода и минимум пояснений по ним). Просто представьте, что читатель первый раз слышит про подобную библиотеку. А вы сходу что-то поверх неё делаете, предварительно не объяснив вообще ничего.
Безусловно вы имеете право и на такой формат. Но такие статьи всегда привлекают меньше внимания. Это факт, а не повод обижаться.
Архитектура для вас это узкоспециальные знания, которые нужны, только когда клиент уже зверски недоволен из-за того, что всё тормозит, а отчёты генерируются часами?
Ясно-понятно.
А в предметную область ты лазил?
Разумеется, как без этого вообще можно хоть что-то путное сделать.
потому что по имени функции было неочевидно, что она делает не только что, что обещает делать в имени
Звучит как «применяйте типы - называйте функции как вам взбредёт». Может, просто неймингу больше внимания уделять? А то ведь и типы можно так обозвать, что будет непонятно что это вообще такое.
Упс, действительно перепутал. У вас просто такой же агрессивный стиль комментариев.
В данном случае, я имею в виду насколько реализация справляется с тем, что нужно на практике. Хоть постановка задачи и конченая, но в ней всё же указано, что мы пишем программу, которая должна тестировать школьников на знание таблицы умножения. Т.е., условно говоря, выдавать 20 примеров и считать сколько из них решено правильно. Очевидно, что для целей такого тестирования необходимо избегать дублирующих примеров, чтобы охватить более существенную часть таблицы.
Решение описанное автором как правильное является наивным, потому что оно примерно в 25% случаев будет генерировать дубликаты примеров. В итоге у вас будет всего 15 из 20 уникальных вопросов. Что ни в какие ворота не годится для объективной проверки знаний.
Странно, что вы как практикующий программист не слышали этот термин. Загуглите "naive algorithm". Оно означает наиболее очевидный способ сделать что-либо, который не учитывает подводных камней.
Это про что вообще? Единственный if, который на всю эту программу нужен - это сравнение введенного ответа с правильным результатом.
Не нервничайте вы так. Тот вариант, который вы в статье описываете как правильный, мне первым пришёл в голову. Но он слишком наивный и не production-ready. Чтобы это понять, достаточно хотя бы минуту подумать над потенциальной бизнес-постановкой.
Просто вам, как учителю информатики, такое направление мыслей недоступно, т.к. вы не являетесь профессиональным программистом.
Во-первых, это не разумеется, т.к. таблица умножения имеет строго фиксированный размер. А во-вторых, в самом снятии этого ограничения нет проблемы. Там появляются другие вопросы:
Будет ли вообще какое-то ограничение, или мы будем тестировать сверхлюдей, которые могут двадцатизначные числа в уме перемножать?
Числа должны быть произвольными или обязательно простыми и больше какого-то минимума? Уж если мы сверхлюдей собрались проверять, то задания должны быть сложными, так ведь?
Кхм. У меня в начале нулевых были уроки информатики на Бейсик-Агат. Слышали про советский аналог Apple II?
К 11-му классу правда завезли PC, так что к урокам информатики добавилось ещё рисование в Paint ?
Или не конвертируется. Смотря как себя проявил. Плюс стажерам обычно вообще не платят, ну или что-то типа стипендии 5-10 т.р.
Можно подумать, они первые это придумали. Всякие стратегии доверительного управления и хедж-фонды давным давно так делают. Там, правда, обычно 2-3% от портфеля безусловно + 20% от прибыли.
Более известный, как нуб)
А относительно работы есть ещё должность "стажёр". Раньше на неё набирали людей с 2-3 годами опыта в программировании для себя.
А мне понравился термин "псевдо-обучение". Он прям так точно описывает все эти онлайн-курсы.
Если добавить к условиям требование, чтобы задания не повторялись в рамках одного прогона программы (что весьма логичное требование для программы, которая тестирует знание таблицы умножения), то вариант иметь заранее сгенерированную структуру данных становится очень даже уместен. Это может быть хеш-таблица, где ключ - произведение, а значение - массив из множителей. В языках с поддержкой метапрограммирования, такое можно на этапе компиляции нагенерить. В остальных - захардкодить.
Сравните:
вариант 1: выбираете одно рандомный ключ, показываете пример и затем убираете это этот ключ из хеш-таблицы (повторяете нужное кол-во раз)
вариант 2: генерируете множители, и начинаете сохранять их произведения в массив и на каждой итерации проверяете, что псевдослучайное произведение не входит в массив, а если входит - перегенерируете пока не сгенерируете нужное.
Второй вариант явно сложнее.
Нет, C++ тоже не особо подходит на роль первого языка.
Я вот тут перечислял из какого списка языков, на мой взгляд, стоит выбирать для начала.
Ну, так то любой может. Более интересный вопрос, сколько вы на этом бабок освоили?
Проблема не в формате экзамена. Проблема возникает, если процесс обучения сводится к натаскиванию на сдачу экзамена (не важно какого формата).
Разумеется, все заголовки являются частью запроса.
Ну, как бы знание основ информатики - это пререквизит к началу обучения программированию. Т.е. знать про кодировки символов, двоичную и шестнадцатеричную системы счисления, про процессы ОС, про стандартный ввод/вывод и т.п. вполне можно до начала обучения программированию.
И, строго говоря, все эти темы не являются частью программирования, они просто используются во время программирования, ну как английский алфавит. Мы ж не говорим, что надо с изучения алфавита обучение программированию начинать?
Ну, разумеется, вы промахнулись почти со всеми додумываниями.
Там не было хайлоада.
Про soft-realtime тоже речи не шло (речь о величинах 4.5 часа vs 50 секунд).
Изначальная архитектура была плоха, и её переделка в менее критичных местах легла в техдолг.
Ну и даже в критически важных юзкейсах не удалось её полностью на адекватную переделать за эти сроки. Даже остался потенциал ускорения ещё раза в 2.
MVP или не MVP, я в любом случае за то, чтобы в начале разработки продумывать архитектуру и понимать что с ней будет при получении реального кол-ва данных, и с запасом x5.
Этим в любом случае придётся озаботиться, чтобы вопрос с капчами решить.
Самокат начал исправлять ситуацию: https://web.samokat.ru/
Думаю, сейчас многие осознают, что не смартфонами едиными юзеры пользуются, и то, что веб-версию можно сделать удобнее, чем мобильную.
Как-то это по-детски обижаться на ресурс и его пользователей. Это ж позиция непризнанного гения (жертвы).
Вы выбрали интересную тему и заход был хороший. Но после "Во всех более-менее современных языках есть библиотеки для работы с денежными суммами, реализующие стандарты и скрывающие от нас адовую арифметику без потерь точности." стоило всё-таки погрузиться в детали как это работает на уровне БД и что там за адовая арифметика без потери точности. Тогда получилась бы статья для широкой аудитории, с параллельным продвижением Elixir.
Как, например, Фаулер продвигал Java своими книгами по рефакторингу и паттернам проектирования.
У вас же получилась узкоспециализованная статья, которая местами выглядит как хвастовство в стиле "во как я могу" (просто фрагменты кода и минимум пояснений по ним). Просто представьте, что читатель первый раз слышит про подобную библиотеку. А вы сходу что-то поверх неё делаете, предварительно не объяснив вообще ничего.
Безусловно вы имеете право и на такой формат. Но такие статьи всегда привлекают меньше внимания. Это факт, а не повод обижаться.
Архитектура для вас это узкоспециальные знания, которые нужны, только когда клиент уже зверски недоволен из-за того, что всё тормозит, а отчёты генерируются часами?
Ясно-понятно.
Разумеется, как без этого вообще можно хоть что-то путное сделать.
Звучит как «применяйте типы - называйте функции как вам взбредёт». Может, просто неймингу больше внимания уделять? А то ведь и типы можно так обозвать, что будет непонятно что это вообще такое.
Если ваш коллега забылся и поставил число не в той СИ или применил не ту формулу, то никакие типы вам не помогут. Только code review и тестирование.