Mikalai Saskavets
@shurph
Engineering Manager / Fullstack Engineer in Web
Information
- Rating
- Does not participate
- Location
- Минск, Минская обл., Беларусь
- Registered
- Activity
Engineering Manager / Fullstack Engineer in Web
Information
Так как оно в итоге получилось? :)
Фактически, получается так называемое изоморфное приложение. Здесь можно почитать подробнее: Изоморфные приложения. Взгляд в будущее с React.
Такие вещи нужны, в первую очередь, тогда, когда вам нужно дать пользователю какой-то сложный интерфейс на странице, а не просто статичный кусок текста статьи, но, при этом, вы хотите, чтобы и поисковики вас хорошо индексировали, и у обычного пользователя статья загрузилась быстро, как будь то это обычный статичный блог-пост, а не SPA, которое может грузиться по несколько секунд.
У нас проект не настолько «контенто-центричен», чтобы писать CMS с нуля на джанге (или чём либо другом).
Пользуясь случаем, хотелось бы узнать, кто какие headless-CMS использует на «бэкенде»? Интересуют свободные standalone решения.
Мы же у себя, на данный момент, остановились на Wagtail в качестве «бэкенда». А в качестве «фронтенда» используем обычное Node.js приложение для пред-генерации страниц для React'а (тот самый server side rendering).
Wagtail — это CMS, построенная на базе Django.
По первым впечатлениям: Wagtail больше заточена для использования её как «классической» CMS, однако имеет встроенный REST API (использует Django REST Framework), позволяющий забирать нужные сущности. Хотя, этот API достаточно негибкий: чтобы получить нужный набор полей сущностей, да ещё и с нужной глубиной вложенности связанных объектов, приходится достаточно много писать кода, обильно снабжая его копипастой из ядра Wagtail.
Интерфейс управления контентом и его редактирования в Wagtail достаточно удобный «из коробки», есть интересная система виджетов. Однако, опять же, для сложных кастомных виджетов приходится писать изрядное количество кода, да и UX начинает страдать.
Мы ещё не достаточно глубоко завязались на этом решении, поэтому было бы классно узнать о хороших альтернативах.
Celery позволяет не только делать периодические задачи с заданными интервалами выполнения, но и отстреливать задачу с чётко заданным временем выполнения, и это время может быть вычислено динамически на основе пользовательских данных или чего либо другого.
Также, кроме просто выноса всех задач на отдельный сервер, можно задачи распределять на выполнение в разные очереди и назначать на каждую очередь своих обработчиков. Это позволяет не стопорить частые и быстрые задачи теми задачами, которые требуют больших ресурсов и работают долго.
Надо заметить, из моего опыта, все сервисы Atlassian работают «неспешно».
Так что, в случае необходимости «и рыбку сьесть и реку в брод перейти», я бы в первую очередь смотрел в сторону гитхаба.
Хотя, наверное, я зря влез с такими замечаниями в топик о битбакете :)
Т.е., как я понимаю, они обращают внимание на сильнокрупные репозитории и не очень рады, когда репозиторий используют не по назначению. А юзкейс may-cat, в котором предполагается хранение изрядного количества бинарных данных (изображений), как раз-таки может попасть под их понимание «не по назначению» :)
В общем, у меня есть некоторые сомнение, что бесплатный план битбакета подойдёт для таких проектов. Из-за вот этой части:
У гитхаба ограничение на размер репозитория в 1 GB (у битбакета также) и строгое ограничение на размер файла в 100 MB. Какие ограничения в этом плане у joltem я не нашел, но вряд ли они сильно отличаются.
Стоит отметить, что есть ещё одна особенность: как видно из вашего же примера, если нужно указать несколько тегов изображений, то для твиттера следует использовать twitter:image0, twitter:image1, twitter:image2, twitter:image3 и т.д., в то время как в Open Graph используется просто og:image для всех изображений.
Opensource, как мне кажется, предполагает отсутствие заказчика. А это ведь памятка заказчику ;)
Но даже без выполнения php-кода, можно встроить в страницу тот же javascript, с помощью которого увести у пользователя cookies или производить манипуляции в админ-панели.
Меня гораздо больше удивляет, что эти горе-хакеры до сих пор пользуются base64 для сокрытия своих скриптов. Действительно, что может быть неприметнее пары килобайт base64 в исполняемом файле? :)
Разве фейк? Здесь, в обсуждениях, максимум к чему пришли — у девушки, возможно, есть приличный опыт за плечами и, возможно, у неё есть наставник/покровитель. Эти выводы никак не опровергают её упорность и дисциплинированность.
Посмотрите на её гитхаб: за 129 дней марафона всего 9 дней пропусков. Я даже на работе не всегда коммичу с таким постоянством, что уж говорить о образовательных проектах ;)
Да, для научных, технических и околотехнических работ он хорош. Мне нравится набирать свои различные отчёты по работам (курсовым, дипломным и т.д.) в LaTeX и очень нравится то, что я при этом минимально беспокоюсь о оформлении (при этом почти что соблюдая ГОСТы ;)).
Однако то же резюме для меня значительно удобнее оказалось набирать в Google Docs. И он для этого подходит практически идеально:
Хотя, в последнее время я подумываю вообще доверить своё резюме linkedin'у и экспортировать doc/pdf из него, если вдруг у HR возникнут такие требования.
PS: мне не очень понравился пример резюме из статьи (думаю, он многих и от LaTeX'а отпугнёт ;)). Слишком неравномерное распределение текста по листу (в некоторых местах налеплено одно на другое, в других — совсем чуть-чуть текста и куча пустого места). Возможно, это из-за «табличности» вёрстки данного конкретного резюме и желания автора впихнуть невпихуемое.
Возможно, со временем, способов применения этих кодов будет всё больше и больше.