• DRF что по ViewSet?

    @javedimka
    Хочу сока
    Использовать нужно то, что соответствует твоим потребностям. Нужна самая простая и обычная функциональность - используй вью сет. Нужно что-то посложнее - используй то, что лежит на уровне ниже.
    Ответ написан
    Комментировать
  • Есть ли для питона шедулер, умеющий очень много задач?

    @MechanID
    Админ хостинг провайдера
    посмотрите на www.celeryproject.org
    Ответ написан
    Комментировать
  • Могли бы вы поделиться хорошим техническим заданием на разработку сайта/веб-приложения?

    solotony
    @solotony
    покоряю пик Балмера
    посмотри мое. Хорошее или плохое сам реши.
    https://vk.com/doc399047259_464509206
    Ответ написан
    Комментировать
  • Как и где хранить техническую документацию?

    DDDsa
    @DDDsa
    Хороший подход — docs as code.
    Мы ведём все документы в git-репозиториях, в формате Markdown. Исходники обёрнуты в Foliant, который может в любой момент из md собрать PDF, docx, сайт, гугл-док или что угодно. Например, многие проекты с документацией автоматически собираются в базу знаний при помощи GitLab-CI. При каждом пуше изменений в репозиторий сайт пересобирается и мы уверены, что там всегда свежие доки. А как только менеджер просит готовый документ — можно тут же собрать PDF, с коропоративным лого и т д.

    При этом исходники всегда лежат в plain-text в репозиториях, что даёт возможность работать над доками вдвоём и втроём, со всеми взрослыми фишками вроде девелоп и мастер веток, фичей, релизов, как будто это код.
    Ответ написан
    Комментировать
  • Как найти не используемые css классы?

    OtshelnikFm
    @OtshelnikFm
    Обо мне расскажет yawncato.com
    Разбивай на компоненты код - и потом на сборку. Как весь мир фронтенд собирает

    В момент когда будешь спагетти css разбирать на секции - ты найдешь неиспользуемые стили.
    Но это в трио: css, html, js - только так найдешь по всем.

    Еще вариант - я вижу что css с душком (без префикса, без BEM и т.д.) - то провожу поиск этого имени по всему проекту. В коде, верстке в js - он найдет все вхождения. Если не найдет - смело удаляй. Но - при условии что ты знаешь как работает проект. А то наломаешь дров если там зависимость от чего-то с третьей стороны идёт.

    css не чистить надо. Его надо разбивать на модули - файлы. И тогда бардака не будет. И объединять все файлы тем же вебпаком
    Ответ написан
    3 комментария
  • Сложный и интересный проект для новичка?

    trapwalker
    @trapwalker
    Программист, энтузиаст
    ## Анонимный чат с темами для обсуждения деликатных офисных проблем
    Иногда хочется обсудить что-то с коллегами в офисе, но не хочется смущать их или показывать лишнюю инициативу.
    Например кто-то не смывает в туалете или слишком громко орёт и сам того не замечает. Может быть кто-то слишком интенсивно пользуется парфюмом.
    - Анонимность
    - Постоянная ссылка на чат, тему или дерево чатов
    - ссылки в виде QR-кодов
    - голосовалка
    - закрепленные посты

    ## Сайт checklist
    Веб-сервис и мобильное приложение для краудсорсинга чеклистов для всего: зарегать ИП, получить визу, что делать при ДТП, как влезть в ипотеку, как вылезть из неё, чем заняться с ребенком на выходных (N-ле

    - Коллекция чек-листов снабженных тегами, доступная для краудсорсинга.
    - Краудфандинг составления и поддержки нового листа.
    - Фильтрация чек-листов.
    - Фильтрация пунктов.
    - Тегирование пунктов.
    - Графовые алгоритм обхода чек-листа.
    - Мастер обхода чек-листа.
    - Отчет по чек-листу.
    - Вложенные чеклисты, гиперссылки между разными листами.
    - Параметризация.
    - Экспертная система, логические связи (расширенный режим).

    Примеры:
    - Что делать при ДТП
    - Открыть ИП
    - Осмотр авто при покупке (подветки для разных конкретных моделей)
    - Первая помощь при...
    - Диагностика инсульта
    - Зомби-акопалипсис: как приготовиться
    - Атомный взрыв неподалёку - что делать
    - Планетарная катастрофа - как выживать
    - Поход выходного дня - что взять
    - Подготовка авто к поездке
    - Путешествие: Алжир (виза, прививки, документы, отели, транспорт)
    - Как влезть в ипотеку
    - Как вылезть из ипотеки
    - Как быстро заработать (во все тяжкие)
    - Покупка квартиры (на что обратить внимание)
    - Самостоятельное строительство дома (общий план)
    - Чем заняться с ребёнком N-лет
    - Как отметить новый год
    - Что интересного в районе <пос. Майский>
    - Номера телефонов и документы в автомобиле

    ## Эротический краудфандинг
    Интернет ресурс, где девушки могут делать крауд-фандинговые кампании

    - Крауд-фандинговая кампания по сбору средств на проект
    - оформление проекта (доказательство личности в виде фото с сигном, некое обещание, порог недовольных результатом, целевая сумма)
    - посетители анонимно финансируют проект в биткоинах
    - если кол-во лайков среди профинансировавших (в соответствии с весами) > порогового, учредитель получает сумму за вычетом комиссии
    - если кол-во лайков не превысило порог, сумма возвращается обратно инвесторам

    ## Простой открытый сервис для обмена сообщениями
    - HTTP API, Web-sockets
    - p2p rtsp
    - опциональное end-to-end шифрование
    - хранение истории на клиентах
    - возможность использования нескольких серверов
    - возможность использования альтруистичных клиентов для проксирования трафика p2p
    - поиск узлов на основе блокчейн технологий и DHT таблиц

    ## Онлайн-журнал путешествия
    - публикация трека в реальном времени
    - комментарии путешественника и фолловеров
    - стримы (аудио, видео, фото)
    - отложенная загрузка
    - журнал(расходы, чек-поинты, расписания, цены, погода)
    - FAQ
    - голосовалка

    ## Поэтический онлайн редактор
    - выбор стопа, стиля и жанра
    - шаблон с плейсхолдерами, разбивающий текст на слоги
    - облако рифм
    - подражающий автогенератор
    - многосегментный словарный банк (дифференциально-слоистая древовидная структура, своя специфика в верхнем слое, поэлементное ранжирование сегментов)
    - тезаурус
    - словарь сочаетаемости
    - N-граммы поэзии по авторам и стилям
    - корпус поэзии
    Ответ написан
    13 комментариев
  • Сложный и интересный проект для новичка?

    @Vaultboy84
    Драг-дроп конструктор сайтов. Можно наворачивать в любую сторону. Шаблоны - css и html.
    Всякие корзины, фильтры товаров - js
    Ответ написан
    Комментировать
  • Аргумент request в функциях Django?

    @antonksa
    Как-то слишком много магии...

    Неужели вы не понимаете, что request не самозарождается внутри функции, как дети в капусте?!

    1. При старте фреймворка джанга ищет все urls.py, вычитывает из них все urlpatterns.
    2. После этого она сохраняет у себя во внутреннем реестре связку урл - функция.
    3. Когда приходит запрос, WSGI вычитывает TCP данные, HTTP данные и формирует WSGIRequest объект всунув в него эту информацию и вызывает главный хендлер джанги.
    4. Хендлер джанги получив этот объект формирует на его основе свой HttpRequest дополняя его джанговскими фичами. После этого находится соответствие урлу и функция обрабатывающаяя этот урл вызывается, с переданным в нее HttpRequest. И кстати не только request. Надо писать:
    def handler(request, *args, **kwargs) -> HttpResponse:
        pass

    потому что джанга может НЕ ТОЛЬКО REQUEST передать в функцию, будете потом тупить, "а почему у меня user_id пишет что не поместилось".

    НЕЛЬЗЯ "№;%% В ВОЗДУХЕ НАПИСАТЬ blabla(request) И ЖДАТЬ ЧТО REQUEST САМОЗАРОДИТСЯ ИЗ НИЧЕГО!!!

    И вообще, у меня сильное ощущение, что вам на три-четыре месяца надо отложить Django и выучить сам питон для начала...
    Ответ написан
    4 комментария
  • Как вести лог действий пользователей django?

    sergey-gornostaev
    @sergey-gornostaev Куратор тега Django
    Седой и строгий
    Навешать на интересующие модели сигналы, в которых просто создавать django.contrib.admin.models.LogEntry.
    Ответ написан
    4 комментария
  • Почему некоторые люди утврерждают что плохо использовать jQuery?

    @xfg
    jQuery - это про императивное программирование. jQuery - это про то "как" манипулировать dom элементами. Итог - смесь dom и бизнес-логики. Это невозможно разделить.

    Angular - это про декларативное программирование. В Angular мы не говорим "как", мы говорим "что" мы хотим сделать с dom и он делает это. Что позволяет отделить бизнес-логику от манипуляций с dom.

    Соответственно вся эта история не про jquery vs vanilla, а про императивное vs декларативное программирование для работы с dom. Большинство этого не понимает и спорят о jquery vs vanilla, хотя всё это одно и то же, до тех пор пока у вас не появляется какая-то штука, которая меняет парадигму работы с dom с императивного на декларативный. Внутри этой штуки можно использовать хоть vanilla, хоть jquery. Без этой штуки - у вас каша, хоть с vanilla, хоть с jquery.

    Собственно об этом написано в википедии:

    AngularJS is built on the belief that declarative programming should be used to create user interfaces and connect software components, while imperative programming is better suited to defining an application's business logic.


    Остальные фреймворки про то же самое. Это и стало причиной стремительного роста популярности javascript фреймворков.
    Ответ написан
    2 комментария
  • Почему некоторые люди утврерждают что плохо использовать jQuery?

    sergey-gornostaev
    @sergey-gornostaev
    Седой и строгий
    Во-первых, jQuery родилась во времена, когда каждый браузер реализовывал JS и DOM API по-своему, её основным назначением было сглаживать эти различия. В наше время это преимущество библиотеки уже утеряно. Во-вторых, jQuery не соответствует основному вызову современности - сложной кодовой базе. В развитом фронте код, использующий jQuery, быстро превращается в трудно сопровождаемую лапшу. Поэтому для простого фронта чаще стали использовать ванильный JS, а для сложного фреймворки типа React, Angular и Vue.
    Ответ написан
    23 комментария
  • Прозрачное сращивание приложения и админки и фронта, как?

    tumbler
    @tumbler Куратор тега Django
    бекенд-разработчик на python
    Админка django (и ее батарейки) - это jquery. Другие фронтенд-технологии прилепить можно, но это будет франкенштейн.
    Лучше или пользоваться стандартной админкой, или писать что-то своё на базе REST API. Стандартная даст хоть и кривенький местами, но быстрый старт, REST со своим фронтом даст полностью подконтрольный дизайн без подпорок еще на стапелях.
    Что касается доступов - их лучше проверять стандартными механизмами Django permissions на бекенде, чтобы всякие кулхацкеры вашу фронтенд-защиту не обошли.

    Или может отказаться от админки и бэка полностью и писать свое?


    Начните с полностью стандартной админки, если интерфейс CRUD не является основной фичей проекта, это сэкономит ощутимое количество времени.
    Ответ написан
    1 комментарий
  • Определение живых пользователей от ботов?

    firedragon
    @firedragon
    Не джун-мидл-сеньор, а трус-балбес-бывалый.
    1. Запрос страниц без картинок (почти однозначно бот)
    2. Время на странице (нужна статистика)
    3. Капча на чувствительные места (регистрация и отправка сообщений)
    4. Регистрация через соц. сети (почти однозначно не бот)
    5. Невидимая кнопка, если перешел сразу бан. (почти однозначно бот)
    6. banner gdpr большого размера и не нажатая кнопка. (почти однозначно бот)
    7. push notification который не нажали на 2 страницах (почти однозначно бот)
    Ответ написан
    7 комментариев
  • При попытки сделать миграции выводятся ошибки, что делать?

    @deliro
    Да
    Ответ написан
    Комментировать
  • При попытки сделать миграции выводятся ошибки, что делать?

    alternativshik
    @alternativshik
    OMG
    import django
    django.setup()

    это кто ж такому учит?
    Ответ написан
    Комментировать
  • Как перестать говнокодить и принимать неверные архитектурные решения?

    miraage
    @miraage
    Старый прогер
    как писать поддерживаемый код?

    Если уж очень коротко, то соблюдать SOLID/GRASP. Мне понравился твит одного из авторов React Router:
    https://twitter.com/mjackson/status/1171524189850701825

    Most common mistake software developers make: putting stuff in the wrong place. Coupling responsibilities and concepts that should be kept separate.
    For me, this is 95% of software development. Just figuring out *where* things belong.


    Что гуглить, что учить?

    Фундаментальные знания, вроде вышеупомянутых SOLID/GRASP, паттерны (не только классические паттерны, но и вообще, общеизвестные решения определённых задач), базовые структуры данных. Фреймворки/библиотеки всегда будут приходить/уходить, что-то будет забываться. А фундаментальные знания всегда актуальны.

    Может литературу какую почитать посоветуете?

    Скажу за себя. Ни одной из этих известных книжек за свою жизнь не прочитал. Писал много говнокода дома, очень много. Удалял, переписывал. Смотрел код других людей, анализировал, пытался перенять то, что считал правильным.

    Можно ли себя называть миддлом, если твой код говно?

    Не пытайтесь себя оценить. В каждой компании свои понятия миддла. А если кто-то 35 лет на лиспе кодил, а потом прыгнет на Angular - кто он, джун или сеньор?
    И, да, все мы в какой-то степени пишем говнокод. Если кто-то Вам доказывает, что он пишет супер чистый код - не слушайте.

    И ответ на главный вопрос.
    Как перестать говнокодить и принимать неверные архитектурные решения?

    Это невозможно. Все проекты, которые чуток сложнее CRUD-ов, рано или поздно обрастают говнокодом. Никто не пишет идеальный код. Код должен работать и решать проблемы бизнеса.
    Ответ написан
    6 комментариев
  • Как написать документацию для приложения?

    lxsmkv
    @lxsmkv
    Test automation engineer
    User story описывает цели которые могут быть достигнуты с помощью приложения. Они определяют пользу. Например, чтобы решить какую задачу выполнить сегодня, пользователь хочет определить самые приоритетные задачи. Польза приложения тут в помощи принятию решений по задачам. Тут нужно думать максимально с т.з конечного пользователя. Зачем он что-то делает и как продукт может помочь ему в этом.

    Use cases будут включать в себя описания какие взаимодействия с приложением пользователь может произвести чтобы достичь своей цели. Например: Отсортировать по приоритету. Отфильтровать по тегам. И пр. По юзкейсам можно проверить, что приложение действительно предоставляет заявленные функции заявленным образом.

    По юзкейсам можно проводить системное тестирование. Т.е. есть заявленный сценарий, работает он или нет.

    Функциональная спецификация определяет детально устройство приложения, с подробным описанием всех технических "если", и "а вдруг".

    По функциональной спецификации пишется реализация, и сам код приложения уже покрывается юнит-тестами.
    Ответ написан
    2 комментария
  • Какой bash-скрипт вы используете для быстрого развертывания стека LAMP на Ubuntu 18.04?

    toxicmt
    @toxicmt
    CTO at hexlet.io
    Для быстрого развертывания сейчас используются три инструмента:

    1. Terraform - управление облачной инфраструктурой. Через терраформ поднимаются сервера, настраивается DNS и многое другое. Кластер поднял, кластер опустил. Работает со всеми облачными провайдерами и ключевыми хостингами.
    1. ansible - управление конфигурацией локальной машины или удаленных серверов. Мастхев инструмент для каждого разработчика. Живой пример https://github.com/hexlet-basics/hexlet_basics/blo... Через него можно и деплоить https://docs.ansible.com/ansible/latest/modules/de... тоже одной кнопкой
    1. Docker - следующий шаг после ansible. Используется либо совместно с Ansible, либо с системами оркестрации, например, kubernetes.

    Ansible, тупой как дрова инструмент, который учится за полдня. Дальше автоматизируйте вообще все что попадается под руку, настройку серверов, разворачивание локального окружения и тому подобное.

    p.s. Посмотрите что еще кроме разворачивания одной кнопкой, хорошо бы сделать https://guides.hexlet.io/check-list-of-engineering...
    Ответ написан
    2 комментария
  • Что делать если youtube занимает слишком много времени?

    DotDash
    @DotDash
    •••• • •−•• •−•• −−− •−− −−− •−• •−•• −•• −−••−−
    Как вариант, прекратить садиться за пк после работы на несколько дней, после чего по таймеру делать рутинные дела не связанные с интернетом, постепенно входя в колею исключающую ютуб. Цель прервать порочный круг.

    Ещё как вариант, разлогиньтесь на ютубе. Алгоритмы трубы работают так, что подбирают наиболее цепкий контент, мимо которого довольно трудно пройти, разлогинившись схема предложений сбросится и вам проще будет переключиться с неинтересного контента на другие дела.
    Ответ написан
    Комментировать
  • Как правильно вести техническую документацию Системному администратору?

    @Madguy
    System Engineer, student in MTUCI
    Присоединяюсь ко всем, кто высказывает я в пользу наличия аккуратно документации. Ниже приведу принципы, которыми успешно пользуюсь сам. Надеюсь, они помогут вам сформировать свое мнение и встать на "светлую сторону" силы.

    Сначала скажу о плюсах документации:
    - она помогает вам учиться грамоно структурировать информацию
    - есть хорошая вероятность, что в будущем вы сами сможете ею воспользоваться и скажете себе "спасибо" (проверено)
    - ею сможет воспользоваться ваш преемник или коллега/руководитель. И, если от преемника вы маловероятно получите какую-либо выгоду кроме морального удовлетворения, то ваш во 2-ом случае это сыграет вам на пользу. Вам будет проще объяснить своему коллеге (да и руководителю) принцип работы, чтобы втянуть его в работу. Руководитель сможет увидеть один из результатов вашей работы, и вы станете более ценным сотрудником в его глазах.
    Тут ещё куча плюсов может нарисоваться, но это самые главные.

    Принципы:
    - пишите документацию так, чтобы человек с минимальными знаниями по теме мог разобраться о чем идёт речь
    - в большинстве статей вы скорее всего будете описывать решение конкретной задачи
    - остальные статьи, верятно, будут иметь описател ный характер (схема сети, расмещение серверов, список доменов, список можете продолжить сами)
    - описывайте только главное, не углубляйтесь в подробности и основы. Для этого есть официальная документация. Вместо описывания основ, дайте ссылку на документацию и пометьте какую информацию там можно найти.
    - ведите структурированную документацию там, где возможно. Введите минимал ные разделы: "описание", "ссылки", "инструкция". "Описание" - здесь пишите какую проблему решаете и что получаете на выходе. "Ссылки" - собираете тут все ссылки, которые указали в статье. "Инструкция" - тут непосредственно сами шаги, которые привели вас к нужному результату. Также в начале этого раздела можно привести список требований (наличие root/админского доступа, наличие нестандартных настроек приложенияя/веб-сервера/системных настроек и тд).
    - в описании или в начале инструкции дайте пару основных определений, которыми будете оперировать в статье.
    - не стесняйтесь приводить иностранную документацию и ссылки, а также не забывайте сами её читать. Сегодня есть отличные инструменты для этого, даже если вы не знаете другой язык. Встроенный переводчик в Google Chrome может перевести сразу всю страницу. Расширение для Google Chrome - LinguaLeo может перевести конкретное слово (пр двойном нажатии на слово)

    Хорошая документация не обязательно требует наличия красивых схем и скриншотов. В большинстве случаев достаточно аккуратного описания. Но в некоторых случаях могут понадобится схемы. Тут можно использовать как скриншоты, так и сделать схему самому. Очень гибкий бесплатный веб инструмент для разных схем - draw.io

    На этом пока все. Есть ещё куча подходов и принципов, а также много литературы и где-то завалялся недавний выпуск подкаста. Если будет интересно - скину, а то с планшета неудобно
    Ответ написан
    1 комментарий