Стандарт де факто — git. Давно ли?
Stackoverflow с 2011 года проводит масштабные опросы разработчиков. В 2022 году в stackoverflow developer survey участвовало более 70к человек из 180 стран. Из-за большого числа участников получаются репрезентативные данные — какие технологии в трендах, куда в целом индустрия плывёт.
Сейчас лидер среди систем контроля версий (СКВ) де-факто Git со своими 97% среди профессиональных разработчиков. Можно выбирать несколько, поэтому сумма больше 100%.
Если переключиться на ответы начинающих разработчиков (скрин ниже), то SVN с 6% падает до 1.5%. Значит, через 3-5 лет в индустрию придут новые разработчики, которые не знакомы с SVN. Кстати, если вы не пользуетесь СКВ, то вы либо в 1.38% профессиональных разработчиков, либо среди 17% новичков. Учите git, любите git.
Ну, и меркуриал почти умер.
А зачем знать тренды? Чтобы не тратить время на умирающий инструмент. Например, какую систему контроля версий посоветовать начинающему разработчику. Вики насчитывает более 30 СКВ. И git был с нами не всегда.
Нашёл для вас опрос 2008 года, где лидер Subversion, скрин ниже. К сожалению, ни числа опрашиваемых, ни процентов у каждой из систем не указано. Тем не менее, git тут и не пахнет, а до настоящего времени дожили №1 SVN и №3 TFVC (они себя сейчас так называют).
В 2014 году на хабре был опрос по СКВ. Результат на скрине ниже — 71% был за git, 32% за SVN, 16% за mercurial, 8% за TFVC от Microsoft.
Так вот git пришёл, запушил, победил. Не исключено, что во многом из-за популярности github.
В телеграмм-канале DevFM разбираем разные нюансы из жизни разработчика на Python и не только. Стримы по программированию, что такое WSGI, миграция БД без даунтайма, чему стоит научиться в вузе, обман нейронных сетей. По пятницам у нас культурный код с фильмами, книгами и всяким разным.
Для чего нужны системы контроля версий или как я понял предназначение GIT
Современный пользователь, запуская приложение\программу\игру\что угодно, на своем компьютере, хочет быть уверенным, даже не так, совершенно не задумывается о том, что в приложении могут быть ошибки\баги\глюки, называй, как угодно, а задача разработчика выпустить продукт таким, чтобы эти самые ошибки и не возникали.
Как это работает:
Сначала разрабатывается идея приложения.
Затем разрабатывается логика его работы.
А после уже логика переносится в код.
Я должен оговориться, что это сильно упрощенная схема, однако, смысл всех этапов разработки примерно такой.
На этапе идеи предусмотреть все ошибки, едва ли получится, так как это просто идея - грубо, описание того, что делает программа или приложение.
Ну согласись, когда у тебя есть только "Эта программа будет текстовым редактором с подсветкой ссылок и отображением их содержимого в правом углу"
- вряд ли ты задумаешься над тем, какие ошибки в работе могут происходить - ты просто описываешь будущий текстовый редактор.
Ты не будешь думать о том, что делать, если пользователь захочет открыть в нем mp3 файл или картинку. Нет, ты просто описываешь свое видение программы.
На этом этапе ты занимаешься только этим, и ни чем другим.
Если переложить это на разработку автомобиля, то ты описываешь автомобиль - автомобиль будет с круглыми окнами, отдельным отсеком для детей и тещи, будет играть кукарачу вместо гудка, и... ну примерно, как тут:
На этапе проработки логики программы, уже возможно предусмотреть некоторые возможные ошибки, но задача в другом, понять, что должна делать программа "внутри" себя, чтобы пользователь получил тот результат, который ему необходим.
Если переложить это с разработки программного обеспечения на разработку автомобилей, то ты проектируешь расположение механизмов под капотом, расстояние между колес, высоту и расположение кресел, да и в целом понимание того, как то, что ты напридумывал на прошлом этапе, заставить работать.
И уже затем, ты начинаешь переносить логику в код. Ну или изготавливать детали, из которых будешь собирать автомобиль, если вдруг решил заняться автомобилестроением вместо разработки программного обеспечения, пока слушал меня.
Затем ты выпускаешь программу, а другие ее скачивают и начинают использовать.
И все бы было хорошо, если бы все пользователи твоей программы, перед ее использованием, прочитали руководство, как ей правильно пользоваться и при работе руководствовались бы им (минутка тавтологии), а еще лучше, думали также, как разработчик.
Но нет, пользователь может совершать то, о чем ты даже и не задумывался.
К тому же, при определенных условиях программа может просто неправильно обрабатывать данные, которые получает.
Например: пользователь захочет поделить на "ноль", а если говорить про автомобиль, раз уж начали, захочет на скорости 100 км\ч включить заднюю скорость или остановиться о дерево.
Скорее всего, результат будет так себе.
По этому, обычно, проводят предварительное тестирования.
Если ты следишь за играми, то скорее всего, слышал о бета-тестах, или же участвовал в таких.
Смысл таких тестов проверить работоспособность и выявить ошибки, при различных сценариях использования программы.
Анализируя полученные данные, ты можешь заблокировать некоторые действия, научить программу работать с нестандартными ситуациями и точнее настроить взаимодействие функций внутри твоей программы, да так, чтобы каждый раз программу не переписывать заново.
Для этого тебе нужно будет внести изменения в код, обновить программу - по сути, добавить в исходный код новый код, да так, чтобы то, что уже работает, продолжало работать.
Именно по этому современный разработчик использует системы контроля версий. Если ты играешь в танки достаточно долго, то возможно, помнишь, что первая версия появилась не сразу. Какой-то длительный промежуток времени игра выходила под версией 0.9 что-то там. Сам я играл 2 боя, и где-то у меня был аккаунт со 100% статистикой побед, как раз за эти 2 боя. Мне не зашло, да и разговор то не об этом, а о том, что разработчики выпустили продукт, который уже как-то работал, и собирая обратную связь и отчеты об ошибках от пользователей, допиливали игру до максимально рабочего состояния.
Используя системы контроля версий, всегда есть возможность вернуться назад, откатиться к предыдущим состояниям кода, если текущая версия работает некорректно, или отказаться от каких либо новых функций, которые просто не нужны.
Особенно актуально вопрос контроля версий стоит в случае коллективной работы над одним проектом.Каждый участник может предлагать свои изменения в программу, без вреда рабочей версии. После одобрения принимающим решение участником, такие изменения можно внести в новую версию.
Именно потому, что системы контроля версий позволяют возвращаться к предыдущему состоянию программы, а также безболезненно работать командой над одним проектом, такие системы приобрели широкую популярность.
Одним из представителей подобных решений является git - не путать с gitHub.
Но об этом не сегодня.
З.Ы. Не уверен, нужен ли тег "Мое", так как Симпсоны - не мое. Да и остальные картинки тоже.
Сможете найти на картинке цифру среди букв?
Справились? Тогда попробуйте пройти нашу новую игру на внимательность. Приз — награда в профиль на Пикабу: https://pikabu.ru/link/-oD8sjtmAi
Учебный python-проект student на gitlab с тестами, часть 1
Периодически приходится объяснять одни и те же детали работы с python в gitlab. Решил записать видео-версию, чтобы покрыть часто возникающие вопросы.
Часовое видео включает в себя полноценную работу в консоли и редакторе vim. Раскрыты следующие аспекты:
1. создание проекта в gitlab
2. консольную работу в git (git status / add / commit / diff / push), в том числе удобные alias для ускорения работы
3. pylint, в том числе выключение некоторых диагностик в тестах
4. создание небольшого проекта на python, в том числе
— база типа запуска hello world, if name == main, f-строк
— три варианта запуска скрипта
— чтение из CSV файла с разделителем "точка с запятой" ФИО и логины
— обработка исключений, в том числе re-raise
— google docstring
— requirements.txt и pip freeze
— проверка наличие логинов на gitlab.com
— разница mv и git mv
— правильная структура проекта
— постоянное использование tab, ctrl+R и прочих практик ускорения работы
— колёсико мышки для вставки буфера выделения
5. создание тестов к проекту с помощью pytest и фикстуры-файла
Код на gitlab. Мой bash конфиг.
В телеграм-канале разбираем разные нюансы из жизни разработчика на Python и не только — python, bash, linux, тесты, командную разработку. Есть разборы фрагментов кода, где в нескольких постах описывается превращение кода "как попало" в хороший. Есть обзоры тенденций (например, выдержки из stackoverflow survey или обзор тенденций систем контроля версий на рынке). Популярен пост как разработчику исследовать предметную область, чтобы не велосипедить и пользоваться топовыми научными достижениями.
На ютуб-канале вы ещё можете посмотреть видео про атаку forkbomb в docker или идеальный скрипт на bash.
На GitHub введут тёмный режим
Об этом в своём твиттере рассказал генеральный директор Github Нат Фридман. А ещё он пообещал, что это будет «лучший тёмный режим, который когда-либо видели».
Что ж, ради «лучшего» подождём.
Источник: https://t.me/tproger_official/6486
Если вы профи в своем деле — покажите!
Такую задачу поставил Little.Bit пикабушникам. И на его призыв откликнулись PILOTMISHA, MorGott и Lei Radna. Поэтому теперь вы знаете, как сделать игру, скрафтить косплей, написать историю и посадить самолет. А если еще не знаете, то смотрите и учитесь.
Bitbucket захвачен сексуальными меньшинствами.
Вот такое я получил сегодня в консоли, запушив изменения
На сайте битбакета тоже есть изменения
По крайней мере их последние изменения в плане ценовой политики получили разумное объяснение.
Пора поднимать свой гитлаб.