Если добавить к условиям требование, чтобы задания не повторялись в рамках одного прогона программы (что весьма логичное требование для программы, которая тестирует знание таблицы умножения), то вариант иметь заранее сгенерированную структуру данных становится очень даже уместен. Это может быть хеш-таблица, где ключ - произведение, а значение - массив из множителей. В языках с поддержкой метапрограммирования, такое можно на этапе компиляции нагенерить. В остальных - захардкодить.
Сравните: вариант 1: выбираете одно рандомный ключ, показываете пример и затем убираете это этот ключ из хеш-таблицы (повторяете нужное кол-во раз)
вариант 2: генерируете множители, и начинаете сохранять их произведения в массив и на каждой итерации проверяете, что псевдослучайное произведение не входит в массив, а если входит - перегенерируете пока не сгенерируете нужное.
Разве речь шла не о том, с чего начинать обучение программированию?
Ну, как бы знание основ информатики - это пререквизит к началу обучения программированию. Т.е. знать про кодировки символов, двоичную и шестнадцатеричную системы счисления, про процессы ОС, про стандартный ввод/вывод и т.п. вполне можно до начала обучения программированию.
И, строго говоря, все эти темы не являются частью программирования, они просто используются во время программирования, ну как английский алфавит. Мы ж не говорим, что надо с изучения алфавита обучение программированию начинать?
Ну, разумеется, вы промахнулись почти со всеми додумываниями.
Там не было хайлоада.
Про soft-realtime тоже речи не шло (речь о величинах 4.5 часа vs 50 секунд).
Изначальная архитектура была плоха, и её переделка в менее критичных местах легла в техдолг.
Ну и даже в критически важных юзкейсах не удалось её полностью на адекватную переделать за эти сроки. Даже остался потенциал ускорения ещё раза в 2.
MVP или не MVP, я в любом случае за то, чтобы в начале разработки продумывать архитектуру и понимать что с ней будет при получении реального кол-ва данных, и с запасом x5.
Лично у меня немного глаз дёргается, когда я захожу на сайт, а там функционала нет и меня отправляют ставить приложение на телефон (привет некоторым службам доставки продуктов)
Как-то это по-детски обижаться на ресурс и его пользователей. Это ж позиция непризнанного гения (жертвы).
Вы выбрали интересную тему и заход был хороший. Но после "Во всех более-менее современных языках есть библиотеки для работы с денежными суммами, реализующие стандарты и скрывающие от нас адовую арифметику без потерь точности." стоило всё-таки погрузиться в детали как это работает на уровне БД и что там за адовая арифметика без потери точности. Тогда получилась бы статья для широкой аудитории, с параллельным продвижением Elixir.
Как, например, Фаулер продвигал Java своими книгами по рефакторингу и паттернам проектирования.
У вас же получилась узкоспециализованная статья, которая местами выглядит как хвастовство в стиле "во как я могу" (просто фрагменты кода и минимум пояснений по ним). Просто представьте, что читатель первый раз слышит про подобную библиотеку. А вы сходу что-то поверх неё делаете, предварительно не объяснив вообще ничего.
Безусловно вы имеете право и на такой формат. Но такие статьи всегда привлекают меньше внимания. Это факт, а не повод обижаться.
Архитектура для вас это узкоспециальные знания, которые нужны, только когда клиент уже зверски недоволен из-за того, что всё тормозит, а отчёты генерируются часами?
Ясно-понятно.
А в предметную область ты лазил?
Разумеется, как без этого вообще можно хоть что-то путное сделать.
потому что по имени функции было неочевидно, что она делает не только что, что обещает делать в имени
Звучит как «применяйте типы - называйте функции как вам взбредёт». Может, просто неймингу больше внимания уделять? А то ведь и типы можно так обозвать, что будет непонятно что это вообще такое.
В начале статьи можно было бы вкратце рассказать как money_sql хранит данные в базе. Для тех, кто с ней не работал, дальнейший текст трудновато будет понять.
А так вообще круто! Действительно удобнее стало.
и сделать это правильно: не в кишках одного из наших микросервисов, и даже не в обособленном внутреннем артифакте, а там, где этому коду самое место: в оригинальной библиотеке, которой пользуются все
Вот это я всячески одобряю. Сам стараюсь так же делать.
Ну понятно, что мы в разных пузырях. Но я реально почти не слышал, чтобы Haskell в какой-то компании для backend-разработки применялся. Там обычно какие-то кодогенераторы, блокчейны, анализаторы и т.п.
Ну, в целом да, так и есть. Чтобы простые задачи быстро выполнять, нужен не опыт и мозг, а тупо набивать руку кол-вом повторений. Люди с высоким уровнем редко таким занимаются, поэтому тут могут быть даже медленнее. Но это уже менеджерский косяк распределения задач.
Более известный, как нуб)
А относительно работы есть ещё должность "стажёр". Раньше на неё набирали людей с 2-3 годами опыта в программировании для себя.
А мне понравился термин "псевдо-обучение". Он прям так точно описывает все эти онлайн-курсы.
Если добавить к условиям требование, чтобы задания не повторялись в рамках одного прогона программы (что весьма логичное требование для программы, которая тестирует знание таблицы умножения), то вариант иметь заранее сгенерированную структуру данных становится очень даже уместен. Это может быть хеш-таблица, где ключ - произведение, а значение - массив из множителей. В языках с поддержкой метапрограммирования, такое можно на этапе компиляции нагенерить. В остальных - захардкодить.
Сравните:
вариант 1: выбираете одно рандомный ключ, показываете пример и затем убираете это этот ключ из хеш-таблицы (повторяете нужное кол-во раз)
вариант 2: генерируете множители, и начинаете сохранять их произведения в массив и на каждой итерации проверяете, что псевдослучайное произведение не входит в массив, а если входит - перегенерируете пока не сгенерируете нужное.
Второй вариант явно сложнее.
Нет, C++ тоже не особо подходит на роль первого языка.
Я вот тут перечислял из какого списка языков, на мой взгляд, стоит выбирать для начала.
Ну, так то любой может. Более интересный вопрос, сколько вы на этом бабок освоили?
Проблема не в формате экзамена. Проблема возникает, если процесс обучения сводится к натаскиванию на сдачу экзамена (не важно какого формата).
Разумеется, все заголовки являются частью запроса.
Ну, как бы знание основ информатики - это пререквизит к началу обучения программированию. Т.е. знать про кодировки символов, двоичную и шестнадцатеричную системы счисления, про процессы ОС, про стандартный ввод/вывод и т.п. вполне можно до начала обучения программированию.
И, строго говоря, все эти темы не являются частью программирования, они просто используются во время программирования, ну как английский алфавит. Мы ж не говорим, что надо с изучения алфавита обучение программированию начинать?
Ну, разумеется, вы промахнулись почти со всеми додумываниями.
Там не было хайлоада.
Про soft-realtime тоже речи не шло (речь о величинах 4.5 часа vs 50 секунд).
Изначальная архитектура была плоха, и её переделка в менее критичных местах легла в техдолг.
Ну и даже в критически важных юзкейсах не удалось её полностью на адекватную переделать за эти сроки. Даже остался потенциал ускорения ещё раза в 2.
MVP или не MVP, я в любом случае за то, чтобы в начале разработки продумывать архитектуру и понимать что с ней будет при получении реального кол-ва данных, и с запасом x5.
Этим в любом случае придётся озаботиться, чтобы вопрос с капчами решить.
Самокат начал исправлять ситуацию: https://web.samokat.ru/
Думаю, сейчас многие осознают, что не смартфонами едиными юзеры пользуются, и то, что веб-версию можно сделать удобнее, чем мобильную.
Как-то это по-детски обижаться на ресурс и его пользователей. Это ж позиция непризнанного гения (жертвы).
Вы выбрали интересную тему и заход был хороший. Но после "Во всех более-менее современных языках есть библиотеки для работы с денежными суммами, реализующие стандарты и скрывающие от нас адовую арифметику без потерь точности." стоило всё-таки погрузиться в детали как это работает на уровне БД и что там за адовая арифметика без потери точности. Тогда получилась бы статья для широкой аудитории, с параллельным продвижением Elixir.
Как, например, Фаулер продвигал Java своими книгами по рефакторингу и паттернам проектирования.
У вас же получилась узкоспециализованная статья, которая местами выглядит как хвастовство в стиле "во как я могу" (просто фрагменты кода и минимум пояснений по ним). Просто представьте, что читатель первый раз слышит про подобную библиотеку. А вы сходу что-то поверх неё делаете, предварительно не объяснив вообще ничего.
Безусловно вы имеете право и на такой формат. Но такие статьи всегда привлекают меньше внимания. Это факт, а не повод обижаться.
Архитектура для вас это узкоспециальные знания, которые нужны, только когда клиент уже зверски недоволен из-за того, что всё тормозит, а отчёты генерируются часами?
Ясно-понятно.
Разумеется, как без этого вообще можно хоть что-то путное сделать.
Звучит как «применяйте типы - называйте функции как вам взбредёт». Может, просто неймингу больше внимания уделять? А то ведь и типы можно так обозвать, что будет непонятно что это вообще такое.
Если ваш коллега забылся и поставил число не в той СИ или применил не ту формулу, то никакие типы вам не помогут. Только code review и тестирование.
Ну, я ж написал, про анализаторы всякие.
Это довольно специфичные применения. Нельзя сказать, что большая часть бэкенда Facebook на Haskell написана, там скорее PHP, а у GitHub - Ruby.
Я имел в виду детали. Что из себя этот пользовательский тип представляет. Плюс дальше ещё MySQL фигурирует.
В целом, можно это и по ссылке в самом проекте посмотреть. Это так, для полноты статьи скорее.
В начале статьи можно было бы вкратце рассказать как money_sql хранит данные в базе. Для тех, кто с ней не работал, дальнейший текст трудновато будет понять.
А так вообще круто! Действительно удобнее стало.
Вот это я всячески одобряю. Сам стараюсь так же делать.
Ну понятно, что мы в разных пузырях. Но я реально почти не слышал, чтобы Haskell в какой-то компании для backend-разработки применялся. Там обычно какие-то кодогенераторы, блокчейны, анализаторы и т.п.
Ну, в целом да, так и есть. Чтобы простые задачи быстро выполнять, нужен не опыт и мозг, а тупо набивать руку кол-вом повторений. Люди с высоким уровнем редко таким занимаются, поэтому тут могут быть даже медленнее. Но это уже менеджерский косяк распределения задач.