Т.е. Вы вообще их в живую не видели и не пользовались что ли?
Пользую трекбол MX-ERGO и вертикальную LIFT. Чтобы привыкнуть к позиционированию не движением руки, но большим шариком - минимум 2 недели. И всё равно скорость точного позиционирования сильно меньше привычных мышей. Кнопки громкие, причём разные кнопки - разной громкости.
LIFT - недорогая и на удивления прекрасная. Очень мягкие и бесшумные основные кнопки - дополнительные - громкие и неприятные, словно нашли на помойке (ими просто не пользуюсь).
Положение руки на LIFT более вертикальное - 2 положения на ERGO всё равно не дотягивают до вертикали Лифта.
Беда в том, что Эппл вчера анонсировала всё тоже самое в своих следующих операционках. Сколько времени пройдёт, когда и в линукс насильно завезут подобное?
Не хочется включать параноика, ибо и так компы и телефоны тьму инфы сливают на сервера, но опасения Маска разделяю. Сначала майки со своим recall, теперь купертиновцы. Как-то не по себе, что твой комп связывает тучу информации и следит за контекстом. "Покажи мне пароль, который прислал Вася вчера."
В постгес тоже можно положить данные в jsonb, настроить индексы и сделать фасетный поиск там. Если данные влезают в toast ~2kb, то поиск довольно резвый.
"Прелесть" всех статей про Чистую Архитектуру - это Абстракция, т.е. возможность использовать слова Парадигма, Подход, Инкапсуляция и пр. Причём, их могут использовать и Знающие люди, и Проходимцы. На выходе мы можем получить как хороший код, так и Фабрику-Фабрик-Репозитория. И отличить Профи от Шарлатана очень сложно. Подобные притчи давно используются в религиях по тем же причинам.
Кстати, сам Боб пишет довольно пространственно, некоторые тезисы бывают слишком радикальны (чувствуете, сюда что угодно можно подтащить). Но выступает - просто блеск! Когда я посмотрел записи его выступления - он делает всё шииииикарно: начинает с забавного отстранённого от ИТ факта, юморит, аппелирует к здравому смыслу. Как дядька, кто хотел сделать разработку лучше - молодец! Как пособник усложнения кода... ну, тут каждый сам решит.
Всё правильно сделали - запустили продукт, сфокусировавшись на самом важном. Да, дизайн устаревший и местами с ошибками - ничего, допилите. В качестве конструктивной критики, про вёрстку https://catalog.app/lite:
У заголовка H1 на мобилках слишком большой шрифт - вылезает за границы. Для английского языка "Boost your sales" всё помещалось бы в экран. Русские "Управленческий" или "Спецпредложение" часто портят покупные темы с бутстрапа.
Дальше текст с центрированием. 2 коротких предложения будут смотреться нормально. 2 абзаца текста с рваным левым краем очень неудобны для чтения.
Для input "запросить демо" можно применить ввод только телефона, чтобы клавиатура на мобильных была с крупными цифрами.
Разрядка текста визуально прыгает в .commun-card H5 - line-height: 1.1 явно маловато.
Подскажите, а какой смысл делать Абстрактный класс class HTTPResponse(ABC) и потом тут же RequestsResponse(HTTPResponse) ? Предполагается ещё какие-то пере-использования и наследования? Какие, например? Спасибо!
Боязнь менять тоже ведь имеет причины. Нет тестов, например. А как проверить? Руками то не всегда получается.
И иногда лучше сохранить стилистику кодовой базы. Если старый проект использует императивный подход из тьмы функций - стоит ли рефакторить, используя ООП? Это вся команда должна решить, а не только один программист-рок-звезда. И придётся подтянуть всю команду в умении делать абстракции.
С ООП бывает сложно перестроить мозг. Смотрю в небо, там облако, похожее на Лошадь. Другому Рыба видится. А ведь всей команда должна уметь в "синхронное плавание".
Определить границу "можно было бы" поможет только опыт. И уровень знаний. Стек тоже сильно влияет на подход. Берёте Java - вы вынуждены использовать интерфейсы. Пишете на Си - там придётся выкручиваться иначе.
Да, когда стоит задача разработать АПИ, ищем человека, который их уже штук 10 сделал и поддерживал долгое время. Используем чужой опыт прямо с носителем этого опыта.
Если нет такого человека, читаем, как делают АПИ, смотрим чужой опыт. Можем мы облажаться? - Конечно. Даже если пытались предусмотреть все возможности по расширению - всё равно у нас хрустального шара предсказывать будущее. Делаем хорошо, насколько можем: пишем тесты и документацию. Ведь совсем не делать тоже нельзя.
Python + Jupyter и прочие Панды и Нампаи стали стандартным набором для аналитиков. Много документации, дополнительный библиотек и обучалок и прочего. И Винда не обязательна (кстати, как её ныне официально купить?).
А вот использовать Эксель (да любой табличный редактор) для хранения и анализа данных - плохая идея. 200 тыс строк - и тормоза. Всё же базы данных для этого придуманы.
Если проект не приносит денег - то его и не надо переписывать. Так бывает: не угадал. Надо высаживать новые розы и выкорчёвывать засохшие, а поливать засохшие нет смысла.
За 25 лет в веб-разработке поменялось всё. И всё несколько раз переписывали.
У API есть версии именно для таких моментов.
Понятно, что надо сначала думать, а потом делать. И не писать лапшу в старом-php стиле.
Джанга вполне себе инструмент. Да, надо помнить об оптимизации, а где не надо?
Что предлагаете? Фастапи? Старлайт? Фласк?
Т.е. Вы вообще их в живую не видели и не пользовались что ли?
Пользую трекбол MX-ERGO и вертикальную LIFT. Чтобы привыкнуть к позиционированию не движением руки, но большим шариком - минимум 2 недели. И всё равно скорость точного позиционирования сильно меньше привычных мышей. Кнопки громкие, причём разные кнопки - разной громкости.
LIFT - недорогая и на удивления прекрасная. Очень мягкие и бесшумные основные кнопки - дополнительные - громкие и неприятные, словно нашли на помойке (ими просто не пользуюсь).
Положение руки на LIFT более вертикальное - 2 положения на ERGO всё равно не дотягивают до вертикали Лифта.
Неплохо-неплохо! Надо затестить!
Беда в том, что Эппл вчера анонсировала всё тоже самое в своих следующих операционках. Сколько времени пройдёт, когда и в линукс насильно завезут подобное?
Как там было в старой песне: Here comes another bubble...
Не хочется включать параноика, ибо и так компы и телефоны тьму инфы сливают на сервера, но опасения Маска разделяю. Сначала майки со своим recall, теперь купертиновцы. Как-то не по себе, что твой комп связывает тучу информации и следит за контекстом. "Покажи мне пароль, который прислал Вася вчера."
В постгес тоже можно положить данные в jsonb, настроить индексы и сделать фасетный поиск там. Если данные влезают в toast ~2kb, то поиск довольно резвый.
Htmx прикольный. Простой и понятный, хорошо подходит для бек-енд разрабов. А вот гиперскрипт как-то не зашёл.
Ещё можно alpine.js вместо с ajax прагином посмотреть — очень похожий функционал, плюс немного реактивности на клиенте. Эдакий упрощённый vue.
Это очень низкий уровень материала. Нет ни одного примера. Ни исходных данных, ни проделанной работы (где что поправили), ни процента в улучшении.
Да, сколько нюансов надо учесть.
"Прелесть" всех статей про Чистую Архитектуру - это Абстракция, т.е. возможность использовать слова Парадигма, Подход, Инкапсуляция и пр. Причём, их могут использовать и Знающие люди, и Проходимцы. На выходе мы можем получить как хороший код, так и Фабрику-Фабрик-Репозитория. И отличить Профи от Шарлатана очень сложно. Подобные притчи давно используются в религиях по тем же причинам.
Кстати, сам Боб пишет довольно пространственно, некоторые тезисы бывают слишком радикальны (чувствуете, сюда что угодно можно подтащить). Но выступает - просто блеск! Когда я посмотрел записи его выступления - он делает всё шииииикарно: начинает с забавного отстранённого от ИТ факта, юморит, аппелирует к здравому смыслу. Как дядька, кто хотел сделать разработку лучше - молодец! Как пособник усложнения кода... ну, тут каждый сам решит.
Всё правильно сделали - запустили продукт, сфокусировавшись на самом важном. Да, дизайн устаревший и местами с ошибками - ничего, допилите. В качестве конструктивной критики, про вёрстку https://catalog.app/lite:
У заголовка H1 на мобилках слишком большой шрифт - вылезает за границы. Для английского языка "Boost your sales" всё помещалось бы в экран. Русские "Управленческий" или "Спецпредложение" часто портят покупные темы с бутстрапа.
Дальше текст с центрированием. 2 коротких предложения будут смотреться нормально. 2 абзаца текста с рваным левым краем очень неудобны для чтения.
Для input "запросить демо" можно применить ввод только телефона, чтобы клавиатура на мобильных была с крупными цифрами.
Разрядка текста визуально прыгает в .commun-card H5 - line-height: 1.1 явно маловато.
Но всё равно - молодцы!
Подскажите, а какой смысл делать Абстрактный класс
class HTTPResponse(ABC)и потом тут жеRequestsResponse(HTTPResponse)? Предполагается ещё какие-то пере-использования и наследования? Какие, например? Спасибо!Боязнь менять тоже ведь имеет причины. Нет тестов, например. А как проверить? Руками то не всегда получается.
И иногда лучше сохранить стилистику кодовой базы. Если старый проект использует императивный подход из тьмы функций - стоит ли рефакторить, используя ООП? Это вся команда должна решить, а не только один программист-рок-звезда. И придётся подтянуть всю команду в умении делать абстракции.
С ООП бывает сложно перестроить мозг. Смотрю в небо, там облако, похожее на Лошадь. Другому Рыба видится. А ведь всей команда должна уметь в "синхронное плавание".
Определить границу "можно было бы" поможет только опыт. И уровень знаний. Стек тоже сильно влияет на подход. Берёте Java - вы вынуждены использовать интерфейсы. Пишете на Си - там придётся выкручиваться иначе.
Да, когда стоит задача разработать АПИ, ищем человека, который их уже штук 10 сделал и поддерживал долгое время. Используем чужой опыт прямо с носителем этого опыта.
Если нет такого человека, читаем, как делают АПИ, смотрим чужой опыт. Можем мы облажаться? - Конечно. Даже если пытались предусмотреть все возможности по расширению - всё равно у нас хрустального шара предсказывать будущее. Делаем хорошо, насколько можем: пишем тесты и документацию. Ведь совсем не делать тоже нельзя.
Python + Jupyter и прочие Панды и Нампаи стали стандартным набором для аналитиков. Много документации, дополнительный библиотек и обучалок и прочего. И Винда не обязательна (кстати, как её ныне официально купить?).
А вот использовать Эксель (да любой табличный редактор) для хранения и анализа данных - плохая идея. 200 тыс строк - и тормоза. Всё же базы данных для этого придуманы.
Если проект не приносит денег - то его и не надо переписывать. Так бывает: не угадал. Надо высаживать новые розы и выкорчёвывать засохшие, а поливать засохшие нет смысла.
За 25 лет в веб-разработке поменялось всё. И всё несколько раз переписывали.
У API есть версии именно для таких моментов.
Понятно, что надо сначала думать, а потом делать. И не писать лапшу в старом-php стиле.
Код на картинке-заставке простой и понятный. Итоговый код заставит напрячься мозг надолго. Чего ради?
Статья призывает задуматься, а надо ли тьма абстракций и наследования, где можно было бы обойтись функцией.