Разве речь шла не о том, с чего начинать обучение программированию?
Ну, как бы знание основ информатики - это пререквизит к началу обучения программированию. Т.е. знать про кодировки символов, двоичную и шестнадцатеричную системы счисления, про процессы ОС, про стандартный ввод/вывод и т.п. вполне можно до начала обучения программированию.
И, строго говоря, все эти темы не являются частью программирования, они просто используются во время программирования, ну как английский алфавит. Мы ж не говорим, что надо с изучения алфавита обучение программированию начинать?
Ну, разумеется, вы промахнулись почти со всеми додумываниями.
Там не было хайлоада.
Про soft-realtime тоже речи не шло (речь о величинах 4.5 часа vs 50 секунд).
Изначальная архитектура была плоха, и её переделка в менее критичных местах легла в техдолг.
Ну и даже в критически важных юзкейсах не удалось её полностью на адекватную переделать за эти сроки. Даже остался потенциал ускорения ещё раза в 2.
MVP или не MVP, я в любом случае за то, чтобы в начале разработки продумывать архитектуру и понимать что с ней будет при получении реального кол-ва данных, и с запасом x5.
Лично у меня немного глаз дёргается, когда я захожу на сайт, а там функционала нет и меня отправляют ставить приложение на телефон (привет некоторым службам доставки продуктов)
Как-то это по-детски обижаться на ресурс и его пользователей. Это ж позиция непризнанного гения (жертвы).
Вы выбрали интересную тему и заход был хороший. Но после "Во всех более-менее современных языках есть библиотеки для работы с денежными суммами, реализующие стандарты и скрывающие от нас адовую арифметику без потерь точности." стоило всё-таки погрузиться в детали как это работает на уровне БД и что там за адовая арифметика без потери точности. Тогда получилась бы статья для широкой аудитории, с параллельным продвижением Elixir.
Как, например, Фаулер продвигал Java своими книгами по рефакторингу и паттернам проектирования.
У вас же получилась узкоспециализованная статья, которая местами выглядит как хвастовство в стиле "во как я могу" (просто фрагменты кода и минимум пояснений по ним). Просто представьте, что читатель первый раз слышит про подобную библиотеку. А вы сходу что-то поверх неё делаете, предварительно не объяснив вообще ничего.
Безусловно вы имеете право и на такой формат. Но такие статьи всегда привлекают меньше внимания. Это факт, а не повод обижаться.
Архитектура для вас это узкоспециальные знания, которые нужны, только когда клиент уже зверски недоволен из-за того, что всё тормозит, а отчёты генерируются часами?
Ясно-понятно.
А в предметную область ты лазил?
Разумеется, как без этого вообще можно хоть что-то путное сделать.
потому что по имени функции было неочевидно, что она делает не только что, что обещает делать в имени
Звучит как «применяйте типы - называйте функции как вам взбредёт». Может, просто неймингу больше внимания уделять? А то ведь и типы можно так обозвать, что будет непонятно что это вообще такое.
В начале статьи можно было бы вкратце рассказать как money_sql хранит данные в базе. Для тех, кто с ней не работал, дальнейший текст трудновато будет понять.
А так вообще круто! Действительно удобнее стало.
и сделать это правильно: не в кишках одного из наших микросервисов, и даже не в обособленном внутреннем артифакте, а там, где этому коду самое место: в оригинальной библиотеке, которой пользуются все
Вот это я всячески одобряю. Сам стараюсь так же делать.
Ну понятно, что мы в разных пузырях. Но я реально почти не слышал, чтобы Haskell в какой-то компании для backend-разработки применялся. Там обычно какие-то кодогенераторы, блокчейны, анализаторы и т.п.
Ну, в целом да, так и есть. Чтобы простые задачи быстро выполнять, нужен не опыт и мозг, а тупо набивать руку кол-вом повторений. Люди с высоким уровнем редко таким занимаются, поэтому тут могут быть даже медленнее. Но это уже менеджерский косяк распределения задач.
И вместо простого сложения чисел (одна инструкция) вы получаете кучу проверок, которые, тем более, надо не забыть везде расставить. Как вы будете проверять, что вы их везде расставили? Опять тесты писать?
Вас увлечение типами к какому-то ужасному дизайну толкает.
Раз уж у нас на входе могут быть единицы в разных системах исчисления, значит и юниты придут в пейлоаде. Там на входе мы их конвертнём в единую СИ и дальше никаких проверок на эту тему не понадобится.
Ага. Elixir, кстати, весьма сбалансированная технология. Сочетает удобство и скорость разработки с производительностью и отказоустойчивостью. На мой взгляд, наиболее ориентированный на нужды бизнеса язык.
Без типов в том, что выкатывается в прод, ошибок находится больше, чаще и серьёзнее, чем в том, что обложено типами.
О, ну хорошо хоть вы не стали утверждать, что со статическими типами ошибок совсем не будет, скомпилировалось же)
Ну а так да, это компромиссный вариант. Edge-кейсы возможны и их риски бизнес принимает ради скорости выкатки. Я б может был не против тоже на Haskell что-нибудь написать, но в 99% случаев бизнес за Haskell платить не готов. Почему так, не знаете?
Это у вас ваш рантайм-чекер должен знать про ваши единицы измерения
В чём проблема, раз уж мы по бизнес-требованием знаем, что они бывают разные?
Это всё, конечно, куда проще и TTMнее, чем просто, блин, использовать типы.
Когда требования постоянно меняются, то да проще и ТТМнее. Опять же, хочется верить, что требования к бортовым компьютерам более стабильны, чем к веб-сервисам.
Проблема не в формате экзамена. Проблема возникает, если процесс обучения сводится к натаскиванию на сдачу экзамена (не важно какого формата).
Разумеется, все заголовки являются частью запроса.
Ну, как бы знание основ информатики - это пререквизит к началу обучения программированию. Т.е. знать про кодировки символов, двоичную и шестнадцатеричную системы счисления, про процессы ОС, про стандартный ввод/вывод и т.п. вполне можно до начала обучения программированию.
И, строго говоря, все эти темы не являются частью программирования, они просто используются во время программирования, ну как английский алфавит. Мы ж не говорим, что надо с изучения алфавита обучение программированию начинать?
Ну, разумеется, вы промахнулись почти со всеми додумываниями.
Там не было хайлоада.
Про 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-разработки применялся. Там обычно какие-то кодогенераторы, блокчейны, анализаторы и т.п.
Ну, в целом да, так и есть. Чтобы простые задачи быстро выполнять, нужен не опыт и мозг, а тупо набивать руку кол-вом повторений. Люди с высоким уровнем редко таким занимаются, поэтому тут могут быть даже медленнее. Но это уже менеджерский косяк распределения задач.
Вас увлечение типами к какому-то ужасному дизайну толкает.
Раз уж у нас на входе могут быть единицы в разных системах исчисления, значит и юниты придут в пейлоаде. Там на входе мы их конвертнём в единую СИ и дальше никаких проверок на эту тему не понадобится.
Ага. Elixir, кстати, весьма сбалансированная технология. Сочетает удобство и скорость разработки с производительностью и отказоустойчивостью. На мой взгляд, наиболее ориентированный на нужды бизнеса язык.
Круто! В Elixir я тоже контрибьютил по мелочи. Но меня частое переключение контекста выматывает.
О, ну хорошо хоть вы не стали утверждать, что со статическими типами ошибок совсем не будет, скомпилировалось же)
Ну а так да, это компромиссный вариант. Edge-кейсы возможны и их риски бизнес принимает ради скорости выкатки. Я б может был не против тоже на Haskell что-нибудь написать, но в 99% случаев бизнес за Haskell платить не готов. Почему так, не знаете?
В чём проблема, раз уж мы по бизнес-требованием знаем, что они бывают разные?
Когда требования постоянно меняются, то да проще и ТТМнее. Опять же, хочется верить, что требования к бортовым компьютерам более стабильны, чем к веб-сервисам.