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

malibujj

Лайки

  • Почему sql запрос возвращает таблицу с пустыми данными при условии is not null?

    @RidgeA
    пустая строка
    Ответ написан
    Комментировать
    Комментировать

  • Почему sql запрос возвращает таблицу с пустыми данными при условии is not null?

    roswell
    @roswell
    и швец, и жнец, и на дуде игрец
    Потому что в поле содержится не NULL, а пустая строка.
    Ответ написан
    2 комментария
    2 комментария

  • Почему запрос выводит только одну запись?

    qonand
    @qonand
    Software Engineer
    ох что-то Вы намудрили, должно быть что-то типа такого
    SELECT
	*
FROM
	clients
INNER JOIN customer ON clients.customer = customer.id_customer
INNER JOIN size_lower_body ON clients.size_lowe_body = size_lower_body.id_lower_size
INNER JOIN size_upper_body ON clients.size_upper_body = size_upper_body.id_upper_size
INNER JOIN messengers ON clients.primary_messager = messengers.id_messenger
INNER JOIN social_networks ON clients.primary_network = social_networks.id_network


    Запрос делал для того, чтобы выводить значения вместо id

    Лучше Вам использовать LEFT JOIN вместо INNER_JOIN
    Ответ написан
    2 комментария
    2 комментария

  • Как обратиться к переменной вне функции в python?

    longclaps
    @longclaps
    В том виде, как у вас - никак. Локальная переменная существует, пока выполняется функция. Вы можете присвоить вычисленное значение свойству объекта:
    def perimeter(self):
        sum_side = self.base_triangle + self.side_b + self.side_c
        print("Периметр треугольника: {}".format(sum_side))
        self.perim = sum_side

    Это, впрочем, довольно грязный код - пользовательский вывод и изменение свойств объекта лучше разнести.
    Ответ написан
    4 комментария
    4 комментария

  • Какую методологию css использовать при верстке?

    tema_sun
    @tema_sun
    Мне rscss.io сейчас нравится.
    Ответ написан
    Комментировать
    Комментировать

  • Как организовать работу в команде с помощью git?

    fshp
    @fshp
    Организацию работы любой работы стоит начать с изучения документации.
    Git не исключение. Git новичку кажется довольно сложной штукой (но на самом деле он очень прост). Поэтому начинать нужно с того, что каждого нужно заставить прочитать Pro Git (или русский перевод "Git для профессионалов"). Читать можно не всё, примерно половину книги занимает информация по администрированию (что рядовому разработчику не нужно). Поэтому времени на изучение уйдёт максимум 5 вечеров.

    Тогда 90% вопросов уйдут сами собой.
    Не будет тупых вопросов "как удалить коммит", "как правильно мержить", "как пушить" и прочее, что часто проскакивает на тостере.

    Из личного опыта.

    Ну а по поводу организации ветвления - каноничный GitFlow, либо более удачный (на мой взгляд) GitlabFlow. Или что-то своё, git на это не накладывает никаких ограничений.

    Поверьте, работа в команде, которая не умеет пользоваться git, превращается в ад и Израиль.
    Ответ написан
    Комментировать
    Комментировать

  • Как организовать работу в команде с помощью git?

    @immaculate
    Программист-путешественник
    Мне кажется, что здесь сложно дать однозначный ответ. Для начала, каждый разработчик должен изучить основные принципы и команды Git. Я много раз сталкивался (и продолжаю сталкиваться) с тем, что разработчики заучивают 2-3 команды (git commit/git pull/git push) и просто долбят их вообще не понимая, что эти команды делают. IDE делают этот процесс еще хуже, потому что там даже не надо задумываться над тем, что вбиваешь, разработчик просто нажимает кнопочку и получает грязь в репозитории. А потом в Slack-чате кричит: «Я все сделал по бумажке! Как мне сказали, сделал git commit и git push, это ваш долбаный git напортачил!» (на самом деле слышал такое и не раз).

    Затем можно сделать репозиторий например, с ветками master и ветками, в которые разработчики добавляют новые фичи (или исправляют баги). Например, add-new-image-upload. Так называемые feature-branch'и. При заканчивании работы в feature-бранче, сливать их с master. Высший пилотаж — делать rebase перед слиянием, чтобы не загромождать историю бесполезными merge commits. Еще боле высший пилотаж — перейти на git-flow, который автоматизирует работу с бранчами master, development, feature branches, hotfixes, release branches. Но забегать вперед не стоит.
    Ответ написан
    Комментировать
    Комментировать