Pull to refresh
-1
0
Mikalai Saskavets @shurph

Engineering Manager / Fullstack Engineer in Web

Send message

Так как оно в итоге получилось? :)

Откуда такая информация, что диплом заочного факультета не считается высшим образованием или не годится для эмиграции?
React на «фронтендовом» бекенде даёт такой профит, что после первой отдачи подготовленного на сервере специального HTML дальше пользователь работает с сайтом как с Single Page Application и данные для следующих страниц сайта уже забираются браузером пользователя непосредственно из API Wagtail'а.

Фактически, получается так называемое изоморфное приложение. Здесь можно почитать подробнее: Изоморфные приложения. Взгляд в будущее с React.

Такие вещи нужны, в первую очередь, тогда, когда вам нужно дать пользователю какой-то сложный интерфейс на странице, а не просто статичный кусок текста статьи, но, при этом, вы хотите, чтобы и поисковики вас хорошо индексировали, и у обычного пользователя статья загрузилась быстро, как будь то это обычный статичный блог-пост, а не SPA, которое может грузиться по несколько секунд.
Wagtail даёт достаточно удобный интерфейс для управления контентом, на первый взгляд. Да, есть трудности по кастомизации этого интерфейса, но пока ещё не понятно, перевешивают ли эти трудности те усилия, которые придётся затратить на написание пользовательского интерфейса работы с контентом на голой джанге. Всё-таки, встроенный веб-интерфейс админки django обычным пользователям показывать нельзя.

У нас проект не настолько «контенто-центричен», чтобы писать CMS с нуля на джанге (или чём либо другом).
Начали использовать похожий подход у себя. Даже не знали, что это называется модным термином headless-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 позволяет не только делать периодические задачи с заданными интервалами выполнения, но и отстреливать задачу с чётко заданным временем выполнения, и это время может быть вычислено динамически на основе пользовательских данных или чего либо другого.

Также, кроме просто выноса всех задач на отдельный сервер, можно задачи распределять на выполнение в разные очереди и назначать на каждую очередь своих обработчиков. Это позволяет не стопорить частые и быстрые задачи теми задачами, которые требуют больших ресурсов и работают долго.
Использую bitbucket для небольших проектов. И даже на этих проектах я чувствую заметные подтормаживания интерфейса, если сравнивать с github. Причём, даже на крупных проектах гитхаб работает отзывчивее битбакета (хотя и подтормаживает на огромных diff'ах и сравнении очень разошедшихся веток).

Надо заметить, из моего опыта, все сервисы Atlassian работают «неспешно».

Так что, в случае необходимости «и рыбку сьесть и реку в брод перейти», я бы в первую очередь смотрел в сторону гитхаба.

Хотя, наверное, я зря влез с такими замечаниями в топик о битбакете :)
Всё же примите вот этот пул-реквест, а то код в .gitignore очень сильно вводит в заблуждение хабровчан :)
Когда я писал про ограничение в 1GB, я как раз опирался на эту ссылку. Особенно вот на этот абзац:
If your repository is greater than 1 GB, you should consider if you are using Bitbucket correctly.
On the free plan? We do expect that you are polite and respect fair use. If you push your entire MP3 collection that is not polite or respectful. Of course, too, if you are using Bitbucket services to do something dishonest or evil – like, say, spamming – that isn't polite or respectful either. We regularly look for these kinds of evil users and remove them.

Т.е., как я понимаю, они обращают внимание на сильнокрупные репозитории и не очень рады, когда репозиторий используют не по назначению. А юзкейс may-cat, в котором предполагается хранение изрядного количества бинарных данных (изображений), как раз-таки может попасть под их понимание «не по назначению» :)

В общем, у меня есть некоторые сомнение, что бесплатный план битбакета подойдёт для таких проектов. Из-за вот этой части:
We regularly look for these kinds of evil users and remove them.
Отчёты и контакты вполне могут быть положены в репозиторий, если выбрать для них подходящий формат (markdown для отчётов и csv для контактов, как пример). Фотографии, в принципе, тоже можно помещать в репозиторий, особенно если предполагается их неизменноть.

У гитхаба ограничение на размер репозитория в 1 GB (у битбакета также) и строгое ограничение на размер файла в 100 MB. Какие ограничения в этом плане у joltem я не нашел, но вряд ли они сильно отличаются.
Замечу, что используемая разметка основана на стандарте Open Graph. Он используется, например, VK и FB, о чем я говорил в начале поста. Единственное отличие — вместо twitter:title, twitter:description и twitter:image используются og:title, og:description, og:image и добавляется og:url, содержащий ссылку на страницу.


Стоит отметить, что есть ещё одна особенность: как видно из вашего же примера, если нужно указать несколько тегов изображений, то для твиттера следует использовать twitter:image0, twitter:image1, twitter:image2, twitter:image3 и т.д., в то время как в Open Graph используется просто og:image для всех изображений.
Ты сам веришь что такое бывает?

Opensource же!

Opensource, как мне кажется, предполагает отсутствие заказчика. А это ведь памятка заказчику ;)
PHP-код не выполнится. Хотя, если функция str_replace переопределена (что можно сделать при использовании неймспейсов), то результат может быть каким угодно.

Но даже без выполнения php-кода, можно встроить в страницу тот же javascript, с помощью которого увести у пользователя cookies или производить манипуляции в админ-панели.

Меня гораздо больше удивляет, что эти горе-хакеры до сих пор пользуются base64 для сокрытия своих скриптов. Действительно, что может быть неприметнее пары килобайт base64 в исполняемом файле? :)
Зашли — и вздохнули с облегчением — «Липа, фейк, это на самом деле нереально, можно расслабиться, все такие же лентяи как и я.»

Разве фейк? Здесь, в обсуждениях, максимум к чему пришли — у девушки, возможно, есть приличный опыт за плечами и, возможно, у неё есть наставник/покровитель. Эти выводы никак не опровергают её упорность и дисциплинированность.

Посмотрите на её гитхаб: за 129 дней марафона всего 9 дней пропусков. Я даже на работе не всегда коммичу с таким постоянством, что уж говорить о образовательных проектах ;)
Учитывая, что у Porsche, Audi, Bentley и Lamborghini вместе взятых наберётся более полусотни моделей, стоимость которых превышает 500 000 $, эти 50 000 фунтов выглядят не такой уж и неподъемной суммой для злоумышленников, которые поставили угон машин на поток. (Хотя, я слабо себе представляю, какой может быть спрос на ворованные автомобили в таком ценовом диапазоне, если честно.)
Кодером? Ада Лавлейс? Вы ничего не путаете?
Какое-то время назад осознал для себя, что использование LaTeX для мелких одноразовых документов — это серьёзный оверкилл.

Да, для научных, технических и околотехнических работ он хорош. Мне нравится набирать свои различные отчёты по работам (курсовым, дипломным и т.д.) в LaTeX и очень нравится то, что я при этом минимально беспокоюсь о оформлении (при этом почти что соблюдая ГОСТы ;)).

Однако то же резюме для меня значительно удобнее оказалось набирать в Google Docs. И он для этого подходит практически идеально:
  • есть экспорт во множество форматов (удовлетворит вкус практически любого HR'а ;)),
  • документ доступен для просмотра/редактирования с любого компьютера где есть браузер (это вам не texlive-full, тянущий 2 гигабайта пакетов),
  • есть какая никакая история изменения (да, это не git, к сожалению)

Хотя, в последнее время я подумываю вообще доверить своё резюме linkedin'у и экспортировать doc/pdf из него, если вдруг у HR возникнут такие требования.

PS: мне не очень понравился пример резюме из статьи (думаю, он многих и от LaTeX'а отпугнёт ;)). Слишком неравномерное распределение текста по листу (в некоторых местах налеплено одно на другое, в других — совсем чуть-чуть текста и куча пустого места). Возможно, это из-за «табличности» вёрстки данного конкретного резюме и желания автора впихнуть невпихуемое.
Полагаю, что неудобства могут возникать из-за таких частых у unix-пользователя зада, как: перекинуть по ssh пару файликов с локального компьютера на удалённый, подключить к локальному компьютеру директорию удалённого компьютера по sshfs и т.д.
А ещё с помощью QR кода можно предоставлять доступ к WiFi сетям для телефонов на ОС Android (возможно, телефоны на других ОС так тоже умеют).
Возможно, со временем, способов применения этих кодов будет всё больше и больше.
1

Information

Rating
Does not participate
Location
Минск, Минская обл., Беларусь
Registered
Activity