Задать вопрос
victor_usachev

Виктор Усачёв

Python Dev
Лайки

  • Гайд по именованию коммитов?

    afiskon
    @afiskon
    Мы обычно делаем так.

    Как правило, одна задача (фича или бага) — один коммит с комментарием «номер задачи: название задачи». Задача пишется в отдельной ветке с кучей коммитов типа fix-fix-fix. Перед pull request коммиты объединяются в один с помощью git rebase. Такой подход позволяет легко откатывать фиксы.

    Если задача очень большая, можно разбить ее на подзадачи или чеклист, тогда каждой подзадаче может соответствовать один коммит. Если нужно сделать небольшое изменение, пишем, например, «0000: minor changes» или «0000: typo fixed».
    Ответ написан
    Комментировать
    Комментировать

  • Что должен уметь backend-разработчик?

    anathem
    @anathem
    На счет php, как подметили, — совсем не обязательно. Логично предположить, что это может быть любой язык, используемый для бэкэнда, — php, ruby, python и т.д. Так же JavaScript может быть использован в качестве языка для бэкэнда в упомянутом node.js.
    В любом случае, если имеется ввиду веб, — JS (и jQuery, ввиду распространенности) обязательно, т.к. использование того же AJAX-а — это все же компетенция бэкэнд-разработчика, а он на JS как раз и основан. Знание верстки так же пригодится, — ведь бэкэнд и фронтэнд, — это часть целой системы и внедрять верстку в проект, вероятнее всего, прийдется тоже бэкэндщику )
    Так что, думаю, «да» :)
    Ответ написан
    4 комментария
    4 комментария

  • Python, PIL, перенос текста

    @phasma
    margin = offset = 40
    for line in textwrap.wrap(text, width=40):
    draw.text((margin, offset), line, font=font, fill="#aa0000")
    offset += font.getsize(line)[1]

    stackoverflow.com/questions/8257147/wrap-text-in-pil
    Ответ написан
    Комментировать
    Комментировать

  • Что почитать по созданию RESTful API новичку ?

    @MikhailEdoshin
    Кстати, я обычно еще всегда ищу и читаю критиков интересующей меня технологии — как правило, там оказывается очень полезная информация, которую от сторонников вы не услышите. Основное это то, что нестандартные для CRUD операции все скопом пойдут теми же POST запросами; что вызов функций получается, так сказать, гетерогенный — часть параметров берется из URL, а часть — из самого запроса; также часть результатов можно вернуть стандартными кодами HTTP, а для части приходится придумывать что-то еще.

    Иногда построенная логическая модель может быть неудобной в реальном использовании — как, например, выразить в REST, запрос типа «найти всех пользователей, интересы которых пересекаются с интересами текущего пользователя»? То есть, субъективно, разработать REST API сложнее, чем C-подобное API. Ну и по мелочам — нет поддержки транзакций, но это для простых сервисов не так важно.

    Пара критических заметок (на английском): 1, 2.
    Ответ написан
    Комментировать
    Комментировать