• Как получить опыт для устройства на работу Python Developer?

    zxmd
    @zxmd
    По опыту набора Python разработчиков могу сказать следующее:
    - Свои проекты на github никого кроме вас самих не волнуют. Ну сами судите - если это проект который никто не фалловит никто не форкает и написан еще кривенько - толку от него мало. Если это реально хорошо написанный код - то это можно использовать как ваш образец написания кода. Мне бы это понравилось, кто то это не учтет.
    - Опыт от 1 года - это не требования, это так сказать фильтр, который отсеит тех кто прочитал книжку "Соц сети за 24 часа для новичков".
    - Фриланс - более менее имеет вес. Но тут палка о двух концах. Я лично бывает звоню по фрилансному контракту и интересуюсь о человеке который выполнил заказ. Тоесть тут надо быть точно уверен что никто из ваших клиентов не скажет "да вы что, он нам проект делал полгода и не доделал" - хотя с вашей стороны будет "да они тз 10 раз меняли и вообще не заплатили за работу". Но обычно уже нет возможности оправдаться. Так что фриланс - не однозначная штука.
    - Голый питон - мало кому из работодателей интересен. Интересует скоп технологий. Если это web то Python+Django+PSQL+PIL+South+Elasticsearch(или sphinx)+mongo+lxml+с полсотни библиотек под разные нужды. Но это я говорю уже о сложившемся синьоре питонисте.
    - По поводу джуниоров. Я при просмотре резюме вообще не смотрю на ЯП (если это не 1c или VB) - язык, в особенности питон - дело 2-3 недель в реальном проекте. Опять по своему опыту - часто приходится переучивать народ с PHP, в этом нет ничего сложного. Многие фирмы идут на это, так как рынок питон разрабов очень ограничен. Как говориться - выращивают бабу-ягу в своем коллективе. Тут главное показать то, что хоть у вас нет опыта - вы этот самый опыт желаете получить..
    Ответ написан
    5 комментариев
  • Гайд по именованию коммитов?

    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 комментария
  • 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.
    Ответ написан
    Комментировать