Еще одна светлая мысль посетила на дня мою беспокойную голову. Ведь и вы, друзья мои, и я читаем ( должны читать) различную литературу, способствующую нашему профессиональному развитию. И тут я понимаю два момента:
- Под литературой я считаю не только книги ( хотя их в первую очередь) — но и статьи, публикации в блогах, распечатку выступления на конференциях ( доклады) и тп.
- Под способствующей развитию я понимаю не только чисто технические вещи, которые «прокачивают» ваши навыки и технические знания но и «философские» вещи — которые заставляют думать правильно, формируют мышление.
Сегодня я хочу поделиться с Вами парой таких книг — как раз одна из них техническая, а вторая — «философская».
Книга 1 — Pro Git
Отдельно хочу сказать спасибо авторам за то, что она находится в открытом доступе. Да, да — несколько переводов книги ( в том числе на русский) находятся в открытом доступе полностью официально — можно читать как с сайта, так и скачать pdf / epub/ amobi версию — https://git-scm.com/book/ru/v2
Прочел не всю — какие-то моменты пропускал, какие-то читал выборочно, по диагонали, кусками или прост просматривал. Таких конечно меньшинство но есть. Просто потому что считаю что на столько серьезное погружение пока мне не нужно — в голове не отложится,а время потрачу.
Сразу хочу упредить очень умных комментаторов, жаждущих воскликнуть «да этож git, чё там читать книжки! Взял документацию и вперёд!» Нет, господа и ещё раз нет!
Я привык, что документация служит в роли справочника, а подобные книги выступают в роли учебника. Сначала получаем представление о возможностях инструмента или технологии читая в учебнике, а в процессе эксплуатации поглядываем в документацию, чтобы вспомнить тонкости. Не говоря, что в книгах зачастую содержится информации больше чем в документации (в качественном смысле, я имею ввиду) — лучшие практики, лайфхаки, условия применимости, внутренне устройство и т. п. сильно облегчающие как повседневную работу, так и какие-то нетривиальные вещи, которые узнать из документации в лучшем случае можно прочтя её от корки до корки, что зачастую непросто из-за «гипертекстового» характера документации, а не подачи материалов путем последовательного усложнения.
Что касается того, что я вынес для себя как Ops инженер, а не разработчик — в 90% случаев важно знать и уметь использовать следующие git команды:
- branch
- checkout
- add
- commit
- merge
- pull/push/fetch
- log
- stash
- status
- reset
- rm
- clone
Различные дополнительные опции и прочие команды — на ваше усмотрение!
Книга 2 — Философия devops. Искусство управления it
Закончив читать данное произведение, так же делюсь впечатлениями от этой книги. Не скажу что это прям зря потраченное время, хотя в итоге я прочел ее не всю — местами довольно много я пролистывал или читал по диагонали.
У меня сложилось впечатление, что эта книга не для инженеров. Не для тех, кто работает непосредственно внутри команды, а скорее для тех, кто занимает позицию Team lead, Manager, Product owner — то есть для тех, кто строить процессы, занимается культурой и привносить организационные идеи. Возможно, я вернусь к этой книге позже, тем более что читать ее можно кусками, спокойно вырывая их из общего контекста и используя как некоторый справочник.
Это не первая книга «для айти», написанная про него но не в технических аспектах. Первыми двумя (из таких) в моей жизни были книги Томаса Лимончелли — «Тайм менеджмент для системного администратора» и «Системное администрирование» — так вот их можно и нужно читать всем. И инженерам, и стажёрам, и начальникам)) Там реальные примеры, практики, советы, методологии.
Здесь же слишком много возвышенного, очень не хватает практических примеров, отображения на какие то, пусть даже придуманные организации и процессы.
Авторы, в стремлении абстрагироваться от конкретных действий и инструментов взлетели слишком высоко. К сожалению.