Всем привет! Меня зовут Иван. И я решил завести этот канал под новый год, чтоб подвести итоги года 🤡
Шутка-шутка.
Уже 13 лет япрограммирую перекладываю жсоны, а в свободное время занимаюсь скалолазанием и перекладыванием жсонов. За это время, у меня накопился определенный багаж опыта и знаний в этой теме, которыми бы я хотел делиться. А еще, я часто бомблю в дискуссиях на тему программирования. Но собираюсь покончить с этой пагубной привычкой! (тут возможен пиздеж)
Поэтому я завел этот канал, где планирую
• Постить всякие мысли по поводу разработки ПО
• Делиться техническими заметками на тему программирования
• Читать ваши комментари, и стараться не бомбить (робота над собой)
• Постить мемасы и шутейки
Так шо подписывайтесь пожалуйста и каментируйте. В свою очередь, обещаю вам не спамить слишком сильно, быть конструктивным и не супер душным ❤️
Шутка-шутка.
Уже 13 лет я
Поэтому я завел этот канал, где планирую
• Постить всякие мысли по поводу разработки ПО
• Делиться техническими заметками на тему программирования
• Читать ваши комментари, и стараться не бомбить (робота над собой)
• Постить мемасы и шутейки
Так шо подписывайтесь пожалуйста и каментируйте. В свою очередь, обещаю вам не спамить слишком сильно, быть конструктивным и не супер душным ❤️
❤13🔥3👨💻3🗿2👾2💩1
Чуть меньше года прошло с моего митапа про юнит тестирование. И вы спросите "Поменялось ли что-то с тех самых пор? Стал ли ты писать тесты по-другому? Как у тебя вообще дела? " А я вам отвечу "Да, кое-что поменялось. Да, стал писать тесты немного по-другому". Сейчас расскажу про это поподробнее. Но прежде всего, давайте напомню основные тезисы с митапа.
Существуют две школы юнит тестирования, основные отличия между которым заключается в том, что именно мы заменяем тестовыми заглушками (моками):
* Классическая школа (КШ) - мокаем только внешние зависимости (кроме базы данных)
* Лондонская школа (ЛШ) - мокаем все зависимости
Соответственно, юнит это:
* Единица поведения в КШ
* Единица кода (метод или функция) в ЛШ
Митап строился по книге Владимира Хорикова "Принципы юнит тестирования". Книгу рекомендую к прочтению. В книге В. Хориков призывает писать тесты с ипользованием КШ. Я с этим мнением не согласен. На митапе я больше тяготел к ЛШ. Про плюсы и минусы обоих школ можно кратко посмотреть в моей презентации.
ЛШ позволяет более простым способом обеспечить полное покрытие тестами (формально). Если есть две зависимости A и B с n и m возможными исходами соотвественно, то в ЛШ мы пишем n + m тестов. В КШ нам прошлось бы написать n * m тестов. Разумеется, если зависимостей больше, то это произведение будет стремительно расти. Лондонская школа дает ощущение достижимости полного покрытия. Даже если ты не ставишь целью достичь 100% покрытия, ты все равно пишешь и пишешь эти тесты. Потому что можешь.
КШ даже не ставит перед тобой подобных задач. Потому что это недостижимо и неважно. Просто покрываем позитивные пути, и, если будет желание, парочку самых важных кейсов с ошибками.
Теперь о том, как изменилось мнение касательно юнит тестов.
Основным минусом ЛШ для меня стало время. В какой-то момент я стал понимать, что не фичи пилю, а тесты. Причем, те баги, что я находил с помощью тестов, могли бы быть найдены и с менее полным покрытием. В итоге я стал сочетать обе школы. Знаете, это будто какой-то переход в зрелость: тебе дают два противоположных подхода, но вместо выбора одного из них, ты начинаешь использовать их как инструменты и выбирать соответствующий под ситуацию.
Приведу (абстрактный) пример из практики. Допустим у вас есть подсистема, которая определяет правила доступа к контенту с очень сложной бизнес логикой. Эта подсистема может состоять из кучи внутренних юнитов. Вместе с тем, есть части системы, которые используют эту подсистему: показ контента, генерация отчетов, подписки и прочее. Тогда наверное имеет смысл использовать КШ для подсистемы правил, а для клиентских частей оставить ЛШ, верно?
Неверно! Это зависит от устройства подсистемы правил доступа. В некоторых случаях будет достаточно сделать именно так. Но, допустим, эта подсистема просто дергает другие подподсистемы, а итоговый результат - это логическое сложение результатов. В этом случае может иметь смысл оставить тестирование с помощью ЛШ, а как раз таки внутренние подподсистемы протестировать классически.
Как определить, где какую школу использовать? К сожалению простого ответа здесь дать не смогу. Как и многое в разработке ПО, выбор школы тестирования - это выбор наиболее компромиссного варианта, основанный на вашем опыте. В данный момент я делаю выбор так, чтоб минимизировать время их написания и количество кода в тестах. В конечном итоге это выливается в вопрос: какая школа обеспечит более простую преподготовку данных при схожем покрытии?
Штош, получилось душновато. Соррян)
Поделитесь в каментах, пишите ли вы юнит тесты? какой подход используете?
Существуют две школы юнит тестирования, основные отличия между которым заключается в том, что именно мы заменяем тестовыми заглушками (моками):
* Классическая школа (КШ) - мокаем только внешние зависимости (кроме базы данных)
* Лондонская школа (ЛШ) - мокаем все зависимости
Соответственно, юнит это:
* Единица поведения в КШ
* Единица кода (метод или функция) в ЛШ
Митап строился по книге Владимира Хорикова "Принципы юнит тестирования". Книгу рекомендую к прочтению. В книге В. Хориков призывает писать тесты с ипользованием КШ. Я с этим мнением не согласен. На митапе я больше тяготел к ЛШ. Про плюсы и минусы обоих школ можно кратко посмотреть в моей презентации.
ЛШ позволяет более простым способом обеспечить полное покрытие тестами (формально). Если есть две зависимости A и B с n и m возможными исходами соотвественно, то в ЛШ мы пишем n + m тестов. В КШ нам прошлось бы написать n * m тестов. Разумеется, если зависимостей больше, то это произведение будет стремительно расти. Лондонская школа дает ощущение достижимости полного покрытия. Даже если ты не ставишь целью достичь 100% покрытия, ты все равно пишешь и пишешь эти тесты. Потому что можешь.
КШ даже не ставит перед тобой подобных задач. Потому что это недостижимо и неважно. Просто покрываем позитивные пути, и, если будет желание, парочку самых важных кейсов с ошибками.
Теперь о том, как изменилось мнение касательно юнит тестов.
Основным минусом ЛШ для меня стало время. В какой-то момент я стал понимать, что не фичи пилю, а тесты. Причем, те баги, что я находил с помощью тестов, могли бы быть найдены и с менее полным покрытием. В итоге я стал сочетать обе школы. Знаете, это будто какой-то переход в зрелость: тебе дают два противоположных подхода, но вместо выбора одного из них, ты начинаешь использовать их как инструменты и выбирать соответствующий под ситуацию.
Приведу (абстрактный) пример из практики. Допустим у вас есть подсистема, которая определяет правила доступа к контенту с очень сложной бизнес логикой. Эта подсистема может состоять из кучи внутренних юнитов. Вместе с тем, есть части системы, которые используют эту подсистему: показ контента, генерация отчетов, подписки и прочее. Тогда наверное имеет смысл использовать КШ для подсистемы правил, а для клиентских частей оставить ЛШ, верно?
Неверно! Это зависит от устройства подсистемы правил доступа. В некоторых случаях будет достаточно сделать именно так. Но, допустим, эта подсистема просто дергает другие подподсистемы, а итоговый результат - это логическое сложение результатов. В этом случае может иметь смысл оставить тестирование с помощью ЛШ, а как раз таки внутренние подподсистемы протестировать классически.
Как определить, где какую школу использовать? К сожалению простого ответа здесь дать не смогу. Как и многое в разработке ПО, выбор школы тестирования - это выбор наиболее компромиссного варианта, основанный на вашем опыте. В данный момент я делаю выбор так, чтоб минимизировать время их написания и количество кода в тестах. В конечном итоге это выливается в вопрос: какая школа обеспечит более простую преподготовку данных при схожем покрытии?
Штош, получилось душновато. Соррян)
Поделитесь в каментах, пишите ли вы юнит тесты? какой подход используете?
❤6🏆3❤🔥2👍2🌭2💊2⚡1
Вместо вонючих итогов года хотелось бы поделиться историей и немножко понастальгировать😊
В далеком 2017-м году я написал простенькое расширение для гугл хрома. Это расширение позволяло скачивать пачками фотографии из диалогов в ВК. Идея создания этого расширения и проблематика, с которой оно борется, будто бы пришли из другой жизни. Тогда трава была зеленее, а солнце светило ярче. В моем 2017-м году ни одна тусовка или мероприятие не обходились без соответствующего сообщества или группы в ВК. После мероприятия, все что было нафотано скидывалось угадайте куда? Ну и, соответственно, там эти фотки оставались ипроябывались забывались. Хотелось как-то достать их оттуда и сохранить куда надо. Так и появилась мысль создать приложение, которое будет решать эту проблему. Прежде всего для меня самого.
Сейчас заканчивается 2024 год. Этот пост я пишу не где-то в ВК, а здесь в телеге. Все мои друзья и знакомые, которые заливали фотки в те самые группы ВК, уже давно перестали это делать. Да и такой потребности больше нет будто😢 Поменялись компании, окружающие люди, города. Встречи стали реже, фоток стало меньше, и они все заливаются в телегу, а не в ВК.
Так почему же сейчас в конце 2024 года я вспоминаю об этом? Последние коммиты я сделал в 2019 году. Я поправил все баги, которые смог найти на тот момент. После этого я напрочь забыл о нем и забил. Но в этом году мне 3 раза написали разные люди по поводу этого расширения. Сначала написал какой-то бухой чел, и я так и не понял че он хотел от меня. А затем прилетели 2 письма - благодарочки с запросами на фичи. После последнего письма я решил чекнуть, как там дела у расширения, и обнаружил, что последний отзыв на него "Не работает". Решил проверить, и оно правда не работало. Оказывается ВК поменял на своей стороне формат ссылок, и оно сломалось. В хром сторе же мне услужливо сообщили, что мое расширение будет скоро удалено, потому что использует старый api. Короче говоря, тлен и безнадега😔
А затем я глянул на статистику использования (см. картинку). Оказывается все эти 5 лет расширением пользовались, да еще как. Я не знаю, кто все эти люди, использующие ВК в 2024, но для меня это было одним из самых приятных и жизнеутверждающих моментов этого года. Ощущение того, что кто-то считает полезным то, что ты сделал, и благодарит тебя за это - бесценно☺️ Вдохновившись, я даже оторвал жопу, чтоб переписать экстеншн на новую версию api, и наконец-то спустя 7 лет выпустил версию 1.0.0 🥳
И вы меня спросите "так в чем же секрет твоего ошеломительного успеха?", а я вам отвечу "jquery, bootstrap и херовый код - вот 3 кита, на которых зиждятся маленькие победы".
Короче выводы:
1. Благодарочка от других людей - это круто и приятно
2. Иногда жизнь преподносит подарки
3. Подарков будет больше, если что-то делать
4. Подарок будет приятнее, если ни на что не надеяться и ничего не ждать
Всех с наступающими, и надеюсь, что грядущий год принесет вам много приятных подарков!🎁
В далеком 2017-м году я написал простенькое расширение для гугл хрома. Это расширение позволяло скачивать пачками фотографии из диалогов в ВК. Идея создания этого расширения и проблематика, с которой оно борется, будто бы пришли из другой жизни. Тогда трава была зеленее, а солнце светило ярче. В моем 2017-м году ни одна тусовка или мероприятие не обходились без соответствующего сообщества или группы в ВК. После мероприятия, все что было нафотано скидывалось угадайте куда? Ну и, соответственно, там эти фотки оставались и
Сейчас заканчивается 2024 год. Этот пост я пишу не где-то в ВК, а здесь в телеге. Все мои друзья и знакомые, которые заливали фотки в те самые группы ВК, уже давно перестали это делать. Да и такой потребности больше нет будто😢 Поменялись компании, окружающие люди, города. Встречи стали реже, фоток стало меньше, и они все заливаются в телегу, а не в ВК.
Так почему же сейчас в конце 2024 года я вспоминаю об этом? Последние коммиты я сделал в 2019 году. Я поправил все баги, которые смог найти на тот момент. После этого я напрочь забыл о нем и забил. Но в этом году мне 3 раза написали разные люди по поводу этого расширения. Сначала написал какой-то бухой чел, и я так и не понял че он хотел от меня. А затем прилетели 2 письма - благодарочки с запросами на фичи. После последнего письма я решил чекнуть, как там дела у расширения, и обнаружил, что последний отзыв на него "Не работает". Решил проверить, и оно правда не работало. Оказывается ВК поменял на своей стороне формат ссылок, и оно сломалось. В хром сторе же мне услужливо сообщили, что мое расширение будет скоро удалено, потому что использует старый api. Короче говоря, тлен и безнадега😔
А затем я глянул на статистику использования (см. картинку). Оказывается все эти 5 лет расширением пользовались, да еще как. Я не знаю, кто все эти люди, использующие ВК в 2024, но для меня это было одним из самых приятных и жизнеутверждающих моментов этого года. Ощущение того, что кто-то считает полезным то, что ты сделал, и благодарит тебя за это - бесценно☺️ Вдохновившись, я даже оторвал жопу, чтоб переписать экстеншн на новую версию api, и наконец-то спустя 7 лет выпустил версию 1.0.0 🥳
И вы меня спросите "так в чем же секрет твоего ошеломительного успеха?", а я вам отвечу "jquery, bootstrap и херовый код - вот 3 кита, на которых зиждятся маленькие победы".
Короче выводы:
1. Благодарочка от других людей - это круто и приятно
2. Иногда жизнь преподносит подарки
3. Подарков будет больше, если что-то делать
4. Подарок будет приятнее, если ни на что не надеяться и ничего не ждать
Всех с наступающими, и надеюсь, что грядущий год принесет вам много приятных подарков!
Please open Telegram to view this post
VIEW IN TELEGRAM
🎉13❤3🔥1
Новогодняя загадка для любимых подписчиков. Как новая аватарка связана с названием канала❓
Об админках.
Представим, что вы работаете с малым или средним бизнесом, и у вас стоит задача, написать бэкенд, рядом с которым обязательно должна быть админка. И по разным причинам вы не хотите иметь дело с CMS. Возможно у вас аллергия на wordpress или вы недостаточно тертый калач, чтоб связываться с Bitrix/Drupal😔
Давайте попробуем разобраться, какие решения для админ панелей существуют на данный момент в разрезе разных языков программирования и технологий. Но прежде, я бы хотел перечислить требования, которым должна удовлетворять хорошая админ панель.
1. Функциональность 🫡. Очевидно, админка должна выполнять свои функции. Причем, это должен быть не просто CRUD для моделей (data grids, формы). В идеале админка должна понимать связи между моделями, и должна давать возможность делать CRUD операции со связанными сущностями. Аутентификация, авторизация - само собой. Должен быть форм билдер - возможность декларативно описывать кастомные формы.
2. Расширяемость 🤏. Из коробки админка должна давать возможность изейше решать 90% всех задач по управлению данными. Но если припрет написать что-то кастомное - такая возможность должна быть доступна без костылей.
3. Популярность 🍑. Какую бы библиотеку вы не использовали, важно быть уверенным, что эта библиотека завтра непревратится в тыкву будет заброшена. Иначе говоря, размер комьюнити вокруг того или иного решения важен. Обычно это коррелирует с количеством звездочек на гитхабе.
4. Нестыдность 👑 (опционально). Внешний вид админ панели должен соответствовать реалиям 2025, а не 2005 года. Это часто сопровождается использованием современных js и css фреймворков под капотом. Но этот пункт я не считаю обязательным, поскольку он вступает в прямое противоречие с пунктом 3, который для меня лично более важен. Тем не менее, я оставляю этот пункт как требование, потому что красивая админ панель может произвести благостное впечатление на пользователей. А пользователи в нашем случае (напоминаю, имеем дело с малым и средним бизнесом), это люди близкие к бизнесу. Так что было бы неплохо, если они были бы довольны красивой админкой, и рассказали бизнесу, какие мы пиздатые разработчики, такую красивую админку запилили.
5. Понимаемость 🤷 (опционально). Здесь речь идет про документацию и примеры, которые обеспечат быстрое погружение и старт разработки. Особое внимание я бы уделил наличию демо. Мне кажется, что работающий живой пример, с доступной кодовой базой - это прям +100 очковгриффиндору привлекательности решения. Опять же, это опциональное требование, поскольку, разобравшись в каком-то решении один раз, дальше это уже не будет проблемой. Если с остальными пунктами все в порядке, на этот пункт мы сможем закрыть глаза со временем. Но к сожалению именно этот пункт может отпугнуть разработчиков в самом начале.
И тут я хочу прерваться, и про конкретные решения поговорить уже в следующем посте.
В комментариях поделитесь, согласны ли вы с требованиями выше, и что бы выхотели добавить или убрать.
Представим, что вы работаете с малым или средним бизнесом, и у вас стоит задача, написать бэкенд, рядом с которым обязательно должна быть админка. И по разным причинам вы не хотите иметь дело с CMS. Возможно у вас аллергия на wordpress или вы недостаточно тертый калач, чтоб связываться с Bitrix/Drupal😔
Давайте попробуем разобраться, какие решения для админ панелей существуют на данный момент в разрезе разных языков программирования и технологий. Но прежде, я бы хотел перечислить требования, которым должна удовлетворять хорошая админ панель.
1. Функциональность 🫡. Очевидно, админка должна выполнять свои функции. Причем, это должен быть не просто CRUD для моделей (data grids, формы). В идеале админка должна понимать связи между моделями, и должна давать возможность делать CRUD операции со связанными сущностями. Аутентификация, авторизация - само собой. Должен быть форм билдер - возможность декларативно описывать кастомные формы.
2. Расширяемость 🤏. Из коробки админка должна давать возможность изейше решать 90% всех задач по управлению данными. Но если припрет написать что-то кастомное - такая возможность должна быть доступна без костылей.
3. Популярность 🍑. Какую бы библиотеку вы не использовали, важно быть уверенным, что эта библиотека завтра не
4. Нестыдность 👑 (опционально). Внешний вид админ панели должен соответствовать реалиям 2025, а не 2005 года. Это часто сопровождается использованием современных js и css фреймворков под капотом. Но этот пункт я не считаю обязательным, поскольку он вступает в прямое противоречие с пунктом 3, который для меня лично более важен. Тем не менее, я оставляю этот пункт как требование, потому что красивая админ панель может произвести благостное впечатление на пользователей. А пользователи в нашем случае (напоминаю, имеем дело с малым и средним бизнесом), это люди близкие к бизнесу. Так что было бы неплохо, если они были бы довольны красивой админкой, и рассказали бизнесу, какие мы пиздатые разработчики, такую красивую админку запилили.
5. Понимаемость 🤷 (опционально). Здесь речь идет про документацию и примеры, которые обеспечат быстрое погружение и старт разработки. Особое внимание я бы уделил наличию демо. Мне кажется, что работающий живой пример, с доступной кодовой базой - это прям +100 очков
И тут я хочу прерваться, и про конкретные решения поговорить уже в следующем посте.
В комментариях поделитесь, согласны ли вы с требованиями выше, и что бы выхотели добавить или убрать.
Продолжаем об админках.
Пробежимся по наиболее популярным технологиям и языкам программирования в попытке составить какую-то картину.
1. golang / nodejs🔤 🔤 🔤 🔤 🔤 . Ну тут все понятно. здесь микрофреймворки, поэтому админок ожидать не приходится.
Вообще чутье подсказывает, что админки стоит искать там, где есть крепкая связка фреймворк + ORM. golang и nodejs не об это совершенно.
2. java (spring). "НИ-ХУ-Я, вот просто НИ-ХУ-Я". Это было одним из сюрпризов. Технология стара, как говно мамонта. Я ожидал, что здесь будет куча решений. Но мои ожидания - это мои проблемы. Нет, какие-то решения все же есть, например SnapAdmin, но это молодая билиотека, и с ней ничего пока неясно. Из популярного есть jhipster, но это генератор кода, который хоть и позволяет нагененрировать UI компоненты (на ангуляре), но это все же не то. Короче говоря, в 2024 году мир java все еще не настроен на быстрые решения для бизнеса.
3. ruby (on Rails). Здесь существуют 2 популярных решения ActiveAdmin и RailsAdmin. И если первое решение еще выглядит современно и построено с использованием всяких TailwindCSS, то второе это просто какая-то бабкина радость (картинка прилагается). Документация ActiveAdmin понятная, но мне показалось, что функционал куций. Я уже говорил про то, что админка должна уметь работать со связями. Здесь это делается при помощи отдельных внутренних страниц, что не есть гуд. Редитторы подтверждают мои опасения, и советуют вообще никаких админок не использовать. Там же некоторые советуют попробовать Avo, который выглядит неплохо и имеет более богатый функционал, но он какой-то полу-платный и звезд на гитхабе меньше. Тут можно посмотреть информацию о всех гемах в категории Rails Admin Interfaces.
4. python (django). Ну тут все просто. В django есть своя админка из коробки, и это очень круто, ведь не надо ничего выбирать. Более того, ее хвалят, потому что у нее богатый функционал, и она очень хорошо кастомизируется. Даже несмотря на то, что дефолтный вариант выглядит простовато и использует jQuery, всегда можно накатить, что-то вроде django-unfold, и вот у вас уже куча красивых виджетов и тейлвинд. Обычно, когда спрашивают про админку, то всегда имеет место сравнение с django admin. Это о многом говорит.
5. php (symfony и laravel). Про symfony скажу кратко: есть EasyAdmin. Ну есть и есть. Много от него ждать не стоит. Он от вас тоже ничего не ждет.
Про Laravel хочется остановиться подробнее, ибо этотговнофреймворк специализируется на том, чтоб вы могли завтра уже в продакшне что-то запустить. И конечно здесь есть своя нативная админка Nova, которая даже хороша, но она платная🤡. И это на фоне того, что кроме Novы, у нас есть еще куча вариантов, а именно Filament, Orchid и сейчас набирает популярность Moonshine. Также есть генератор Backpack.
Для своего пет проекта я вот как раз выбрал Filament, и мне тут есть что сказать. Во-первых, это 20к звезд на гитхабе, это своя экосистема с плагинами, это возможность делать свои свистелки-перделки на фронтенде, не написав ни одной строчки js. Это больше чем просто админка. Filament базируется на технологии Livewire, которая позволяет писать динамичные фронтенд компоненты на пхп. И конечно же у этого всего есть обратная сторона: Filament непростой в освоении. Что-то пошло не так - все, ты в очке. Что - то не работает - ты в очке. Ты читаешь доку - ты в очке. Короче, ты часто в очке первое время. Но когда ты не в очке, ты счастлив. Ведь у тебя столько всего работает из коробки, и оно такое красивое, а ты при этом пхпист.
Orchid и Moonshine хорошие админки, и они не уступают Django admin. Обе просты в освоении, и приятны на глаз. Но к сожалению, ни одна из них не сможет дать тебе тех же ощущений от разработки, что дает Filament.
6. ASP.NET. Простите, дотнетчики, мне это не интересно=) Но вроде там есть платные админки какие-то
В заключении хочу сказать, что админ панель - это довольно серьезное бизнес требование. Для нового проекта может иметь смысл сократить пару сотен часов разработки, выбрав соответствующую технологию.
Пробежимся по наиболее популярным технологиям и языкам программирования в попытке составить какую-то картину.
1. golang / nodejs
Вообще чутье подсказывает, что админки стоит искать там, где есть крепкая связка фреймворк + ORM. golang и nodejs не об это совершенно.
2. java (spring). "НИ-ХУ-Я, вот просто НИ-ХУ-Я". Это было одним из сюрпризов. Технология стара, как говно мамонта. Я ожидал, что здесь будет куча решений. Но мои ожидания - это мои проблемы. Нет, какие-то решения все же есть, например SnapAdmin, но это молодая билиотека, и с ней ничего пока неясно. Из популярного есть jhipster, но это генератор кода, который хоть и позволяет нагененрировать UI компоненты (на ангуляре), но это все же не то. Короче говоря, в 2024 году мир java все еще не настроен на быстрые решения для бизнеса.
3. ruby (on Rails). Здесь существуют 2 популярных решения ActiveAdmin и RailsAdmin. И если первое решение еще выглядит современно и построено с использованием всяких TailwindCSS, то второе это просто какая-то бабкина радость (картинка прилагается). Документация ActiveAdmin понятная, но мне показалось, что функционал куций. Я уже говорил про то, что админка должна уметь работать со связями. Здесь это делается при помощи отдельных внутренних страниц, что не есть гуд. Редитторы подтверждают мои опасения, и советуют вообще никаких админок не использовать. Там же некоторые советуют попробовать Avo, который выглядит неплохо и имеет более богатый функционал, но он какой-то полу-платный и звезд на гитхабе меньше. Тут можно посмотреть информацию о всех гемах в категории Rails Admin Interfaces.
4. python (django). Ну тут все просто. В django есть своя админка из коробки, и это очень круто, ведь не надо ничего выбирать. Более того, ее хвалят, потому что у нее богатый функционал, и она очень хорошо кастомизируется. Даже несмотря на то, что дефолтный вариант выглядит простовато и использует jQuery, всегда можно накатить, что-то вроде django-unfold, и вот у вас уже куча красивых виджетов и тейлвинд. Обычно, когда спрашивают про админку, то всегда имеет место сравнение с django admin. Это о многом говорит.
5. php (symfony и laravel). Про symfony скажу кратко: есть EasyAdmin. Ну есть и есть. Много от него ждать не стоит. Он от вас тоже ничего не ждет.
Про Laravel хочется остановиться подробнее, ибо этот
Для своего пет проекта я вот как раз выбрал Filament, и мне тут есть что сказать. Во-первых, это 20к звезд на гитхабе, это своя экосистема с плагинами, это возможность делать свои свистелки-перделки на фронтенде, не написав ни одной строчки js. Это больше чем просто админка. Filament базируется на технологии Livewire, которая позволяет писать динамичные фронтенд компоненты на пхп. И конечно же у этого всего есть обратная сторона: Filament непростой в освоении. Что-то пошло не так - все, ты в очке. Что - то не работает - ты в очке. Ты читаешь доку - ты в очке. Короче, ты часто в очке первое время. Но когда ты не в очке, ты счастлив. Ведь у тебя столько всего работает из коробки, и оно такое красивое, а ты при этом пхпист.
Orchid и Moonshine хорошие админки, и они не уступают Django admin. Обе просты в освоении, и приятны на глаз. Но к сожалению, ни одна из них не сможет дать тебе тех же ощущений от разработки, что дает Filament.
6. ASP.NET. Простите, дотнетчики, мне это не интересно=) Но вроде там есть платные админки какие-то
В заключении хочу сказать, что админ панель - это довольно серьезное бизнес требование. Для нового проекта может иметь смысл сократить пару сотен часов разработки, выбрав соответствующую технологию.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6🆒2
Screenshot 2025-01-18 at 17.18.45.jpeg
18.3 KB
Тока шо наткнулся на настоящий бриллиант нейминга. Это как раз в коде Filament. Го в комментах делиться аналогичными находками в библиотеках. Посмотрим, у кого длинее😏
😁7🤯1👌1
Сегодня у нас обзор на книгу Адама Беллемара "Создание событийно-управляемых микросервисов".
Плюсы:
* Качественная бумага
* Разборчивый шрифт
* Страницы перелистываются
Минусы
* Содержание
* Перевод
Данная книга - прекрасный образец бесполезной книги по программированию. Когда ее читаешь, то ты можешь находиться в одном из двух состояний: ты все понимаешь, потому что ты уже это знаешь, либо ты ничо не понимаешь и не поймешь после прочтения. Причем второе состояние возникает чаще первого. Перехода между состояниями нет.
Автор любит наваливать очень много абстрактного текста, приправленного столь же абстрактными картинками (см. фото). Из этой книги вы не узнаете про типы коммуникации между микросервисами (например, что такое pub-sub или 2 queues request-response), не узнаете, что такое transaction outbox или CQRS, и вы даже не увидите ни одной строчки реального кода микросервиса. Да и реальных примеров не будет. Зато будет много тескта в стиле "учитывайте бизнес требования! читайте документацию! занимайтесь физкультурой! снимайте штаны, прежде чем покакать!" 💪
Мне кажется на обложке книги изображен сам автор. Иначе, я не могу объяснить, откуда вообще весь этот текст взялся.
И если содержание книги похоже на торт из трижды переваренного кала, то перевод книги - вишенка на этом торте. Переводчик здесь оторвался по полной. Например, deadlock внезапно перевели как виртуальный тупик🤡 Шаблон sidecar - это, оказывается, КОЛЯСКА!!! не знали, да? попытка загуглить "шаблон коляска" выдает трафареты детских колясок😁 И, наконец, мое любимое: repartioning перевели как переподразделение, а copartioning как соподразделение. Можно развить идею. Например, если хочется немножко переподразделить что-то, то это будет подпереподразделение🤡
Короче автор и переводчик - это прям Биба и Боба. Один зачем-то высрал ненужный трактат ни о чем, другой это приправил "колясками". В итоге, читать невозможно, да и не сильно то нужно.
Какой вывод? Не все книги полезны. Не будьте как я, читайте отзывы перед покупкой😘
Плюсы:
* Качественная бумага
* Разборчивый шрифт
* Страницы перелистываются
Минусы
* Содержание
* Перевод
Данная книга - прекрасный образец бесполезной книги по программированию. Когда ее читаешь, то ты можешь находиться в одном из двух состояний: ты все понимаешь, потому что ты уже это знаешь, либо ты ничо не понимаешь и не поймешь после прочтения. Причем второе состояние возникает чаще первого. Перехода между состояниями нет.
Автор любит наваливать очень много абстрактного текста, приправленного столь же абстрактными картинками (см. фото). Из этой книги вы не узнаете про типы коммуникации между микросервисами (например, что такое pub-sub или 2 queues request-response), не узнаете, что такое transaction outbox или CQRS, и вы даже не увидите ни одной строчки реального кода микросервиса. Да и реальных примеров не будет. Зато будет много тескта в стиле "учитывайте бизнес требования! читайте документацию! занимайтесь физкультурой! снимайте штаны, прежде чем покакать!" 💪
Мне кажется на обложке книги изображен сам автор. Иначе, я не могу объяснить, откуда вообще весь этот текст взялся.
И если содержание книги похоже на торт из трижды переваренного кала, то перевод книги - вишенка на этом торте. Переводчик здесь оторвался по полной. Например, deadlock внезапно перевели как виртуальный тупик🤡 Шаблон sidecar - это, оказывается, КОЛЯСКА!!! не знали, да? попытка загуглить "шаблон коляска" выдает трафареты детских колясок😁 И, наконец, мое любимое: repartioning перевели как переподразделение, а copartioning как соподразделение. Можно развить идею. Например, если хочется немножко переподразделить что-то, то это будет подпереподразделение🤡
Короче автор и переводчик - это прям Биба и Боба. Один зачем-то высрал ненужный трактат ни о чем, другой это приправил "колясками". В итоге, читать невозможно, да и не сильно то нужно.
Какой вывод? Не все книги полезны. Не будьте как я, читайте отзывы перед покупкой😘
🤣11😁2❤1🫡1
Я капец как не люблю и не умею рисовать. Каждый раз, когда мне надо что-то где-то изобразить, у меня происходит вспотевание лба и других частей тела. Даже если я использую что-то вроде draw.io, где уже есть куча готовых элементов - перетаскивай и используй - у меня всегда выходит какой-то разноцветный кал 🌈
Поэтому я все больше проникаюсь декларативным рисованием диаграмм. В частности, мне очень зашел mermaid🧜♀️
Под "декларативным рисованием" я подразумеваю работу с диаграммами с помощью специального конфигурационного файла. Непосредственная отрисовка диаграмм отводится ПО, которое принимает на вход этот файл, а на выходе получается уже готовая картинка. Любые изменения в существующей диаграмме делаются через модицикацию конфига.
Именно так и работает mermaid. Отрисовка диаграммы выполняется в контексте определенной нотации, например Flowchart, Entity Relationship, Gantt и др. Mermaid поддерживает более 20 различных нотаций. Для каждой нотации существует свой описательный язык.
Очевидные плюсы такого подхода, по сравнению с традиционными рисовалками в стиле "драг-н-дроп прямоугольник":
* стандартизованность - единое представление одних тех же типов элементов
* diagram as code с возможностью положить диаграмму в vcs и отслеживать историю изменений
* local first approach (привет obsidian и его клоны)
Но существует также и неочевидный плюс. Подобный подход позволяет думать, рисуя. Потому что я не отвлекаюсь на построение лэйаута для элементов, выравание их, покраску, выбор размера шрифта и прочие очень важные действия. Все эти проблемы уже решили за меня. Вместо этого я могу сконцентрироваться на сути диаграммы, на абстрактном отношении между ее элементами. А ее визуальное представление помогает мне понять, чего не хватает или что здесь лишнее. При таком подходе диаграмма выступает одним из инструментов проектирования.
Подобное можно испытать не только в mermaid. Например, существует C4 нотация для построения диаграммы архитектуры ПО. Чаще всего C4 используется для документации уже существующей архитектуры. Однако недавно мне довелось заниматься проектированием системы с нуля (в рамках обучающего курса, ничего серьезного). Я использовал PlantUML для построения С4 диаграммы этой системы. И в какой-то момент, поймал себя на мысли, что я проектирую с использованием этой диаграммы, используя PlantUML в качестве языка проектирования. Очень круто!
А какие же минусы такого подхода? Главный и наверное единственный минус - нужно разобраться в нотации и в описательном языке выбранного инструмента. Это потребует от вас какое-то время на вкатывание. Но благо, в том же memaid документация строится на конкретных примерах. Так что пара часов максимум - и вы уже шарите в этой теме.
Но даже в этом минусе я вижу плюс. Вам надо будет изучить нотацию выбранного типа диаграммы, а значит, у вас будет правильное понимание примитивов данной нотации, вы не изобразите нестандартизованную херню.
В общем, если вы часто чего-то рисуете с помощью перетаскивания стрелочек, то я рекомендую попробовать посмотреть в сторону mermaid и подобного тулинга. Если вы редко рисуете, то тут уже на ваше усмотрение. В таком случае проще может быть накидать что-то драг-н-дропом, чем разбираться в документации.
В комментах поделитесь, где вы рисуете ваши диаграммы?
Поэтому я все больше проникаюсь декларативным рисованием диаграмм. В частности, мне очень зашел mermaid🧜♀️
Под "декларативным рисованием" я подразумеваю работу с диаграммами с помощью специального конфигурационного файла. Непосредственная отрисовка диаграмм отводится ПО, которое принимает на вход этот файл, а на выходе получается уже готовая картинка. Любые изменения в существующей диаграмме делаются через модицикацию конфига.
Именно так и работает mermaid. Отрисовка диаграммы выполняется в контексте определенной нотации, например Flowchart, Entity Relationship, Gantt и др. Mermaid поддерживает более 20 различных нотаций. Для каждой нотации существует свой описательный язык.
Очевидные плюсы такого подхода, по сравнению с традиционными рисовалками в стиле "драг-н-дроп прямоугольник":
* стандартизованность - единое представление одних тех же типов элементов
* diagram as code с возможностью положить диаграмму в vcs и отслеживать историю изменений
* local first approach (привет obsidian и его клоны)
Но существует также и неочевидный плюс. Подобный подход позволяет думать, рисуя. Потому что я не отвлекаюсь на построение лэйаута для элементов, выравание их, покраску, выбор размера шрифта и прочие очень важные действия. Все эти проблемы уже решили за меня. Вместо этого я могу сконцентрироваться на сути диаграммы, на абстрактном отношении между ее элементами. А ее визуальное представление помогает мне понять, чего не хватает или что здесь лишнее. При таком подходе диаграмма выступает одним из инструментов проектирования.
Подобное можно испытать не только в mermaid. Например, существует C4 нотация для построения диаграммы архитектуры ПО. Чаще всего C4 используется для документации уже существующей архитектуры. Однако недавно мне довелось заниматься проектированием системы с нуля (в рамках обучающего курса, ничего серьезного). Я использовал PlantUML для построения С4 диаграммы этой системы. И в какой-то момент, поймал себя на мысли, что я проектирую с использованием этой диаграммы, используя PlantUML в качестве языка проектирования. Очень круто!
А какие же минусы такого подхода? Главный и наверное единственный минус - нужно разобраться в нотации и в описательном языке выбранного инструмента. Это потребует от вас какое-то время на вкатывание. Но благо, в том же memaid документация строится на конкретных примерах. Так что пара часов максимум - и вы уже шарите в этой теме.
Но даже в этом минусе я вижу плюс. Вам надо будет изучить нотацию выбранного типа диаграммы, а значит, у вас будет правильное понимание примитивов данной нотации, вы не изобразите нестандартизованную херню.
В общем, если вы часто чего-то рисуете с помощью перетаскивания стрелочек, то я рекомендую попробовать посмотреть в сторону mermaid и подобного тулинга. Если вы редко рисуете, то тут уже на ваше усмотрение. В таком случае проще может быть накидать что-то драг-н-дропом, чем разбираться в документации.
В комментах поделитесь, где вы рисуете ваши диаграммы?
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6🦄1
Если же говорить о не декларативных рисовалках, то приятным открытием прошлого года стал Excalidraw. Это тот редкий случай, когда простота и "красивость" выделяет продукт среди конкурентов. Вы только посмотрите на стиль получающихся картинок! Это супер мило😍
В excalidraw очень "примитивная" стандартная библиотека примитивов, что также является плюсом по мне. Но если хотите, можно скачать кучу готовых специализированных библиотек.
Из недостатков: это local first тулза. Синхронизация и колаборация доступны только в платной версии. Приходится ставить расширение для хрома, чтобы манагерить свои рисунки.
Но эти минусы почему-то не отпугивают пользователей. 90к звезд на гитхабе говорят сами за себя ⭐️
Кстати, на собесах по системному дизайну часто используют именно excalidraw. И мне кажется, что причина в его простоте. Люди без проблем разбираются, как им пользоваться в процессе.
В excalidraw очень "примитивная" стандартная библиотека примитивов, что также является плюсом по мне. Но если хотите, можно скачать кучу готовых специализированных библиотек.
Из недостатков: это local first тулза. Синхронизация и колаборация доступны только в платной версии. Приходится ставить расширение для хрома, чтобы манагерить свои рисунки.
Но эти минусы почему-то не отпугивают пользователей. 90к звезд на гитхабе говорят сами за себя ⭐️
Кстати, на собесах по системному дизайну часто используют именно excalidraw. И мне кажется, что причина в его простоте. Люди без проблем разбираются, как им пользоваться в процессе.
✍4🔥1
На работе уважаемые разработчики из индии за 3 недели накидали прототип микросервиса с использованием python фреймворка FastAPI. Моя задача теперь выкинуть весь код к хуям довести прототип до ума. Решил подойти к задаче, как профи. Поэтому потратил неделю на изучение этого вашего питона и FastAPI. И знаете, это капец сложно! Ниже поясняю за базар.
Немного вводных данных. FastAPI - фреймворк, который построен на асинхронном питоне (asyncio), т.е. мы везде имеем наши любимые async - await. Вроде после js проблем быть не должно. FastAPI имеет очень подробную документацию. Она будто для дебилов написана и затрагивает не только сам фреймворк, но даже разработку на python в целом.
Но FastAPI начал меня страпонить практически сразу. Сначала я решил познакомиться с миграцией баз данных. В документации меня ждала лишь ссылка на библиотеку alembic. Сама по себе библиотека потная и душная. Самые душные миграции в моей жизни. Однако при тестировании все миграции применялись к public схеме в постгресе. И я никак не мог понять, а как блэт поменять схему-то. Благо, я оказался такой не один, и ребята тем же вопросом задались. Еще и оказалось, что с асинхронным драйвером там свои танцы с бубнами. Пиздец 🤡
Далее, как передать database connection во все хэндлеры запросов? Я слышал, что в FastAPi есть DI. Решил познакомиться с ним поближе. Он странный. Но в доке написано "This is very useful when you need to... Share database connections". "Отлично! А как? Как мне создать пулл коннекшнов при старте приложения, а потом использовать их везде?" Нет ответа в доке! А люди-то тоже интересуются в интернете, например тут и тут. Ребята из индии на каждый запрос к бд коннектятся от безысходности😔
Тоже самое про MQ. Захотел при старте приложения подконнектиться к Rabbit MQ и слушать, че там происходит. Вроде разобрался, как при старте FastAPI коннекшн сделать. Вопрос, где его хранить, ведь он потом еще понадобится для отправки сообщений? Ну положил в глобальную переменную, штош 🤡 Кстати, у драйвера aio-pika для Rabbit MQ периодически отваливается коннекшн без реконнекта или эксепшна. Приложение тихонько перестает слушать, че там у вас в очереди происходит. Пока хз, че с этим делать. Будем смотреть.
Лан, давайте про сам питон. Стоит ли говорить, что большая часть всего, что есть в интернете по питону - это про синхронный питон. Ансинхронщина же будто припиздрячена костылями к этому самому синхронному питону. Изза этого часто непонятно, а какую библиотеку выбрать. Например, есть мегапопулярный адаптер для постгреса psycopg. Но он изначально был без поддержки asyncio. Но щас вроде завезли в 3й версии. Но почему-то все советуют asyncpg. Тоже самое с клиентом для RabbitMQ, потому что есть синхронный pika (но с asyncio коннектором), а есть aio-pika.
Если хочешь в бэкграунде че-то поделать с помощью asyncio.create_task, то обязательно надо сохранить куда-то сам task, потому что, если этого не сделать, то сборщик мусора может эту корутину удалить. Так в доке написано. Я прям охерел с этой прикормки 😳 Самое прикольное, что в инете все примеры че то забивают на это. Хз, что делать, на всякий случай в глобальную переменную все сохранил. Люблю глобальные переменные 😊
Кстати, захотел эту переменную с тасками типизировать, ну типа указать, что у меня тут коллекция Taskи хранит. Так и не понял как это сделать! Где типы для asyncio?
IDE помогает слабо. Куча библиотек написана без типов.
context manager (ну это который with pampam() as huita) проглатывает исключения 😳 я так понимаю, это зависит от реализации конкретного менеджера. но все же, для меня это не совсем ожидаемое поведение. Неожиданно и то, что исключения тупо пропадают в корутине, которая task в бэкграунде.
logger из коробки не работал че-то у меня. Ну вот ребята со стэкоферфлоу помогли.
Вообщем, может создаться впечатление, что я тут жалуюсь. Но это не совсем так. Это я свой опыт пытаюсь переложить на незнакомый инструмент. И он ложится неидеально, это нормально. Надо подпривыкнуть 😊 Надеюсь, получится освоить этот популярный язык, и наконец-то по-настоящему войти в айти!💪
Немного вводных данных. FastAPI - фреймворк, который построен на асинхронном питоне (asyncio), т.е. мы везде имеем наши любимые async - await. Вроде после js проблем быть не должно. FastAPI имеет очень подробную документацию. Она будто для дебилов написана и затрагивает не только сам фреймворк, но даже разработку на python в целом.
Но FastAPI начал меня страпонить практически сразу. Сначала я решил познакомиться с миграцией баз данных. В документации меня ждала лишь ссылка на библиотеку alembic. Сама по себе библиотека потная и душная. Самые душные миграции в моей жизни. Однако при тестировании все миграции применялись к public схеме в постгресе. И я никак не мог понять, а как блэт поменять схему-то. Благо, я оказался такой не один, и ребята тем же вопросом задались. Еще и оказалось, что с асинхронным драйвером там свои танцы с бубнами. Пиздец 🤡
Далее, как передать database connection во все хэндлеры запросов? Я слышал, что в FastAPi есть DI. Решил познакомиться с ним поближе. Он странный. Но в доке написано "This is very useful when you need to... Share database connections". "Отлично! А как? Как мне создать пулл коннекшнов при старте приложения, а потом использовать их везде?" Нет ответа в доке! А люди-то тоже интересуются в интернете, например тут и тут. Ребята из индии на каждый запрос к бд коннектятся от безысходности😔
Тоже самое про MQ. Захотел при старте приложения подконнектиться к Rabbit MQ и слушать, че там происходит. Вроде разобрался, как при старте FastAPI коннекшн сделать. Вопрос, где его хранить, ведь он потом еще понадобится для отправки сообщений? Ну положил в глобальную переменную, штош 🤡 Кстати, у драйвера aio-pika для Rabbit MQ периодически отваливается коннекшн без реконнекта или эксепшна. Приложение тихонько перестает слушать, че там у вас в очереди происходит. Пока хз, че с этим делать. Будем смотреть.
Лан, давайте про сам питон. Стоит ли говорить, что большая часть всего, что есть в интернете по питону - это про синхронный питон. Ансинхронщина же будто припиздрячена костылями к этому самому синхронному питону. Изза этого часто непонятно, а какую библиотеку выбрать. Например, есть мегапопулярный адаптер для постгреса psycopg. Но он изначально был без поддержки asyncio. Но щас вроде завезли в 3й версии. Но почему-то все советуют asyncpg. Тоже самое с клиентом для RabbitMQ, потому что есть синхронный pika (но с asyncio коннектором), а есть aio-pika.
Если хочешь в бэкграунде че-то поделать с помощью asyncio.create_task, то обязательно надо сохранить куда-то сам task, потому что, если этого не сделать, то сборщик мусора может эту корутину удалить. Так в доке написано. Я прям охерел с этой прикормки 😳 Самое прикольное, что в инете все примеры че то забивают на это. Хз, что делать, на всякий случай в глобальную переменную все сохранил. Люблю глобальные переменные 😊
Кстати, захотел эту переменную с тасками типизировать, ну типа указать, что у меня тут коллекция Taskи хранит. Так и не понял как это сделать! Где типы для asyncio?
IDE помогает слабо. Куча библиотек написана без типов.
context manager (ну это который with pampam() as huita) проглатывает исключения 😳 я так понимаю, это зависит от реализации конкретного менеджера. но все же, для меня это не совсем ожидаемое поведение. Неожиданно и то, что исключения тупо пропадают в корутине, которая task в бэкграунде.
logger из коробки не работал че-то у меня. Ну вот ребята со стэкоферфлоу помогли.
Вообщем, может создаться впечатление, что я тут жалуюсь. Но это не совсем так. Это я свой опыт пытаюсь переложить на незнакомый инструмент. И он ложится неидеально, это нормально. Надо подпривыкнуть 😊 Надеюсь, получится освоить этот популярный язык, и наконец-то по-настоящему войти в айти!💪
❤3🤔1🤯1🤡1🏆1