00:00 Вступление
00:27 Английский язык
02:43 Декомпозиция
03:51 Возможности фреймворков
04:37 Базы данных
05:37 Веб-сервисы
06:33 Сетевые протоколы
07:24 UI-фреймворки
08:16 Особенности языка программирования
Друзья, в этом видео я расскажу вам о том, что такое Git, зачем он нужен, как его использовать и как с его помощью оптимизировать и упростить работу в команде. Мы поговорим обо всех особенностях использования этого инструмента и я наглядно покажу как с ним работать.
Что такое git?
Git — это система контроля версий, а если сказать простым языком то это программа, инструмент, которая позволяет нам фиксировать наши изменения в коде, а также благодаря этой фиксации позволяет нескольким людям или даже командам вместе слажено и параллельно работать над каким-то программным продуктом.
Представьте что вы пишите программу и у вас есть какая-то функция, которая допустим сохраняет информацию информацию о пользователе в базу данных, и для этого сохранения вам естественно нужна логика которая собственно это сохранение будет делать. Вот вы написали код, все круто все работает. Как сделать своего рода сохранение как в компьютерной игре которое сможет зафиксировать прогресс?
Git — это как раз такая программа, такая система, которая позволяет эти сохранения создавать и потом управлять ими, менять, возвращаться к ним, удалять и переписывать их, такая фиксация в терминах Git-а называется `commit`
Проще всего гит представлять по аналогии либо с компьютерной игрой и ее сохранениями либо с таким роботом-фотографом, который в любой момент который вы ему скажете сделает так сказать фотографию ваших файлов с которыми вы работаете, зафиксирует их состояние на текущий момент, и затем любой момент может вам сказать поменялось ли что-то в этих файлов с момента прошлой «фиксации».
Git собственно так и делает, вы говорите ему команду, он запоминает состояние ваших файлов на текущий момент присваивая ему специальный номер вот это снимка, там называемый `commit hash`.
Commit hash — набор символов которые уникально идентифицируют сохранение состояния файлов в конкретный момент времени;
Что такое ветки в гите и как их использовать?
В git также используется так называемая система веток, представьте себе что ветка, так называемая branch — это маршрут по которому едет поезд, а каждая его остановка, сохранение состояния это коммит. То есть когда мы начинаем разрабатывать какую-то задачу, пишем код нам нужно идти с точки А в точку Б, у нас скажем пустой файл, а потом постепенно наш код начинает эволюционировать и он со временем начинает что-то внятное делать.
Так вот этот процесс разработки можно представить по той же аналогии с поездом, поездвыезжает с точки А и ему нужно доехать до точки Б, и этот маршрут он будет ехать по своему пути (в нашем случае это и будет ветка нашего git), а также по пути ему надо останавливаться чтобы фиксировать свой прогресс по маршруту, это и будут коммиты в нашем случае, то есть мы пишем код в рамках ветки и делаем коммиты, для того чтобы сохранять наш прогресс внутри метки.
Как его используют команды?
Как такой подход позволяет нам распараллелить работу разных людей и команд и сделать их более продуктивными? Все дело в том что когда мы работаем над каким-то проектом и нескольоко людей пишут код они во 1 могут одновременно менять одни и те же файлы.
Так вот фишка гита в том что каждый разработчик может сам себе создать такую ветку, уникальный маршрут поезда на пути которого будут свои уникальные остановки, то есть свои уникальные коммиты этого разработчика, и эта ветка она будет скажем так принадлежать одному человеку и там он будет фиксировать все свои изменения, делать коммиты.
И все сводится к достаточно простой логике, у нас есть какой-то код который нам надо написать, мы сделали новую ветку, по пути того как мы разрабатываем мы в этом ветке делаем коммиты чтобы зафиксировать изменения, как только мы понимаем что у нас все готово, нам нужно объединится с другими разработчиками, скажем так сделать так чтобы наши изменения ехали по общему маршруту, то мы просто сливаем все наши коммиты из нашей ветки в общую. По аналогии с поездами можно представить что у нас есть какая-то главный поездной маршрут в котором есть все наши остановки, коммиты из всех веток. Таким образом все довольно просто, сделали ветку, написали код попутно фиксируя изменения коммитами, после того как закончили, слили все наши изменения в общую ветку чтобы эти коммиты, эти изменения были доступны всем другим разработчикам.
00:00 Начало
1:03 — Git — что это?
2:52 — Что такое Git commit
4:09 — Ветки или «branch» что это такое?
5:27 — Как команды используют Git?
7:49 — Как применять Git в работе. Практика.
7:57 — Новый репозиторий. (Git init)
9:17 — Создание файла и коммита. (Git commit)
11:46 — Сохранение файлов (Git commit -m)
12:46 — Как работают с ветками и какими они бывают.
14:51 — Создание develop ветки, и ветки для работы ( Git checkout -b feature)
17:06 — Как новый файл добавляется в Git
19:39 — Откат к коммиту (Git reset)
20:44 — Слив на одну ветку (Git merge)
Основу подхода заложили два японских специалиста Hirotaka Takeuchi, Ikujiro Nonaka в статье The New New Product Development Game, от 1996 год. В статье обобщили опыт нескольких японских корпораций (Xerox, Toyota, Nec и другие), работающих с принципиально новыми продуктами. Ключевая идея статья заключалась в формировании самоорганизующихся команд, которые делают короткие итерации, автономны от других, мотивированы на результат командными целями, и повышает мастерство друг друга делясь друг с другом опытом.
С течением времени под этот подход формировалось все больше и больше проектных методик, пока в 2001 году на горнолыжном курорте не произошла встреча 17 специалистов по разработке ПО. На этой встрече была сформирована общая система ценностей по управлению проектами, в дальнейшем получившая название Agile – манифеста. 4 ценности и 12 принципов легли в основу множества методов согласно подходу Agile.
1. Люди и взаимодействие важнее процессов и инструментов;
2. Работающий продукт важнее исчерпывающей документации;
3. Сотрудничество с заказчиком важнее согласования условий контракта;
4. Готовность к изменениям важнее следования первоначальному плану.
Таким образом, не отрицая важности того, что справа, всё-таки больше ценится то, что слева.
C 2001 подход Agile существенно расширил свои границы и вышел за пределы IT-бизнеса. Теперь под зонтиком Agile находятся многие управленческие и инженерные фреймворки по управлению проектами, формируя зонтик Agile. Под этот зонтик попадают подходы Scrum и Kanban, Crystal и экстремальное программирование (XP), а также другие системы управления и инженерные практики.
Важно понимать, что Agile подходы работают не всегда, и Дейвом Снойденом была разработана Кеневин модель, которая показывает, что использовать экспериментальные практики, коими являются подходы Agile, можно в ситуациях, когда не до конца очевидны причинно-следствие связи проекта, цель представляет собой скорее видение, образ, а стоимость переделок не запредельно высока.
Тем ни менее, в случае инноваций и проектов с высокой степенью неопределенности, подходы Agile являются наилучшими из существующих в современном мире.
В этом видео мы посмотрим какие следы оставляет программа, запущеная в операционной системе Linux. Как можно проанализировать к каким северам она подключается и какие файлы читает.
Я расскажу, как искать проблемы на живых серверах, как смотреть в логи (grep, perl), как смотреть, что происходит с системой (top, vmstat, iostat, tcpdump) и как смотреть в coredump’ы.
Здравствуйте
В этом видео я расскажу вам, как создать собственный очень дешевый домашний Облачный сервер, используя дешевые детали.и Nextcloud. домашний Dropbox