Структура How To Become A Hacker?

Why This Document?

What Is a Hacker?

Тут без комментариев, просто читайте оригинал.

The Hacker Attitude

1. The world is full of fascinating problems waiting to be solved. ✔️

2. No problem should ever have to be solved twice. ✔️

3. Boredom and drudgery are evil. ✔️

4. Freedom is good. ✔️

5. Attitude is no substitute for competence.✔️

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

Basic Hacking Skills

1. Learn how to program. ✔️

2. Get one of the open-source Unixes and learn to use and run it. ✔️

3. Learn how to use the World Wide Web and write HTML. ✔️

4. If you don't have functional English, learn it. ✔️

Status in the Hacker Culture

1. Write open-source software ✔️

2. Help test and debug open-source software

3. Publish useful information ✔️

4. Help keep the infrastructure working ✔️

5. Serve the hacker culture itself ✔️

Ставлю галки на том, что стараюсь сам делать, хотя получается не всегда :)
В статье по каждому пункту написано достаточно, не буду повторять.

2/3

Структура How To Become A Hacker?

The Hacker/Nerd Connection

это комментарий про связь хороших инженеров (The Hacker) и нёрдов (Nerd); спойлер: её почти нет, это всё выдумки массмедиа

Points For Style

Сюда отдельно обратите внимание.

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

Historical Note: Hacking, Open Source, and Free Software

Other Resources

Frequently Asked Questions

Эту часть тоже рекомендую полистать, там есть ссылки на хорошие вещи.

3/3

а ещё вот: пёся-почтальон

Что точно учить из языков разметки я рассказал (база?).

Вот тут материалы, по которым можно научиться самостоятельно.
(Надеюсь, скоро всё-таки выложу это добро на omp.wiki, пора!)

0) Необходимо сесть и начать писать на этих языках (вот неожиданность!).

1) LaTeX: хватит установить какой-нибудь дистрибутив (TexLive/MacTex или даже MikTex), большинство нужных вам вещей будет идти из коробки. Или открыть Overleaf, но будьте готовы, что эта штука отупляет.

И прочитать Short Math Guide for LaTeX, там всего 21 страница, но они покрывают 95% ваших сценариев на ближайшие много лет.

2) HTML и CSS лучше учить по референсу на Mozilla Developer Networks (вообще, кажется, именно Mozilla сделала чуть ли не больше всех для того, чтобы веб-разработка была адекватной; в т.ч. поддерживают этот референс в актуальном состоянии): HTML и CSS.

В части про CSS особенно обратите внимание на flexbox и grids -- сейчас всё верстается на них, как минимум, потому что удобно.

Весь референс учить не имеет смысла (только если вы не собрались быть frontend-разработчиком, тогда как раз хватит выучить весь референс), но пролистать разик-другой очень рекомендую, пригодится.

JavaScript сходу учить не советую, в современности уже лучше учить TypeScript, а только потом почитать какую-нибудь книгу о том, в чём именно JS так больно.
После Python, кстати, TS учится очень легко: TS -- это такая чуть более здоровая версия петона, если угодно :)

+ нужен примерно любой браузер и Developer Tools в нём; там и html любой страницы можно посмотреть и свою открыть и поредактировать, и есть консолечка для js;

3) GNU Texinfo: устанавливаете пакет texinfo любимым пакетным менеджером (скорее всего, его не будет в вашем дистрибутиве по умолчанию), а дальше в терминале info texinfo и внимательно читаете + полистать статью, которую уже упоминал выше.

(Подробно на omp.wiki о том, как пользоваться этим гну инфо: тыньк).

бубнёж про языки разметки совсем всё, дальше постепенно напишу про то, кто такой девопс, млопс и другой опс (спойлер: если вы хорошо знаете POSIX Shell и Linux, то вот вы уже почти какой-то опс)

и, пожалуй, кое-что ещё про софтскиллы

не стесняйтесь ставить лукасы, чтоб это произошло побыстрее — так я пойму, что это стоит сделать :)

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

Частей будет несколько, пока не знаю сколько точно.

Не стесняйтесь задавать вопросы в комментах (и ставить лукасы!), можно и про эти посты, можно и про общее — буду стараться отвечать, вероятно, такими же постами. Возможно, что-то очевидно мне и совсем неочевидно вам.

Кто такой DevOps и что такое DevOps?
Часть 1 из ...

Development and Operations (DevOps) -- акроним, которым описывается набор практик (и иногда даже правил), направленных в первую очередь на автоматизацию и непрерывность доставки программного обеспечения.

Раньше как было?

Разработчики написали код => передали код тестировщикам => тестировщики потестировали и передали код людям, которые могут собрать код в готовый пакет/релиз (операционные инженеры) => инженеры опубликовали, приложение доступно конечному пользователю.

Каждый из этапов обычно изолирован и идёт строго после окончания предыдущего.

А сбоку сисадмины помогают всему предприятию не умереть.

Как сейчас?

Девопсы поддерживают скрипты для автоматизации, поддерживают пайплайны CI/CD, часто инфраструктуру, наводят репозиторий и даже культуру, админят стенды.

Разработчики пишут код, складывают его в git-репозиторий => автоматически запускаются нужные тесты, проверки кода => когда нужно, (по нажатию одной кнопки, но) автоматически раскатывается релиз => тестировщики могут тестировать => конечный пользователь получает ПО.

Ни один из этапов можно не останавливать, пока тестировщики тестируют очередной релиз, разрабы могут продолжать шлёпать код в git-репозиторий, unit-тесты будут работать и т.д.

Нагрузка на сисадминов сильно меньше, часть инфраструктурных задач теперь сгружена на DevOps-инженеров.

Что изменилось?

Как можно было заметить, в основном доставка ПО из-за DevOps стала непрерывной + по возможности полностью заскриптована.

Соответственно, ещё раз, можно определить DevOps как совместную работу людей над разработкой, направленную на непрерывное создание и доставку безопасного программного обеспечения с максимальной скоростью.

Обратная связь при этом быстрая, а разработка итеративная.

Какие инструменты используют DevOps-инженеры?
Часть 2 из ... про devops

1. Какой-нибудь из shell и почти точно Linux. (shell и Linux в этом предложении можно менять местами, смысл не поменяется).

Как и всегда: лучше POSIX Shell, но чаще всего встречается именно bash.

Почему shell основной? Ну, потому что удобно, потому что все инструменты разработки работают в первую очередь в Linux, а он целиком и полностью автоматизируется средствами shell.
Потому что Linux невозвожен без shell.

2. Git. Нынче всё в нём, никакие другие системы контроля версий сейчас уже почти не используются (а если используются, то зачем??).

Это маст хэв.

3. Контейнеры.

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

Опять же, внутри контейнера в 99.99% случаев будет Linux, а чтобы навести контейнер нужно будет писать shell.

Чаще всего это Docker-контейнеры, намного реже LXC, Docker сейчас де факто стандарт (хотя и к этому у меня много вопросов!), потыкайте на досуге https://hub.docker.com/, там уже много образов на любой чих. Дописать свои из них тоже очень просто (когда-то про это расскажу или напишу на omp.wiki)

4. Какой-нибудь из инструментов Continous Integration.

Это такие инструменты, в которых можно описать последовательность шагов, которые нужно сделать, например, при создании Pull Request.
Или при выкатке приложения для пользователей. Или чего ещё угодно, что Вы и Ваша команда додумаетесь там написать.

Все, кто слушали ОМП в Вышке, такие уже видели, в домашках был Drone CI (сейчас, кстати, лежит хах): когда сдавали домашку, на каждый ваш PR проходило несколько шагов:

- flake8, чтобы проверить, что Вы пишете нормальный питон
- pyright для проверки, что правильно написали типы
- тесты

описание было прям в корне репозитория, в drone.yml.

Вот также и в реальной жизни, хотя обычно и чуть сложнее.

CI бывают разные: Jenkins, Gitlab CI, Github Actions, Drone CI, TeamCity и др.
Чаще всего для описания шагов в CI будет использоваться yaml (или какой-нибудь DSL, вплоть до Kotlin script в Teamcity), но в каждом из шагов в любом инструменте CI будет написан shell скрипт.

Инструменты Continous Delivery тут же (если не теже самые, что и для CI), работают также.

Какие инструменты используют DevOps-инженеры?
Часть 3 из ... про devops

5. Часто какие-нибудь инструменты автоматизации инфраструктуры.

Например, Ansible (хотя не только его, бывает Puppet, SaltStack и другое).

Ansible -- это штука, в которой можно описать набор хостов (прям серверов, которые где-то запущены и работают), написать на yaml последовательность шагов которые нужно выполнить на этих хостах.

Ansible скомпилирует yaml в shell (да именно такой кошмар), подключится к этим хостам по ssh и просто выполнит их, прям в shell.

Да, там есть больше деталей, но, опять же, если вы хорошо знаете shell и Linux, то хватит 3-5 дней, чтобы начать на нём активно и хорошо писать.

6. Инструменты мониторинга. Тут зверьков много, они разные, но чаще всего это
- Zabbix
- Prometheus/InfluxDB для сбора метрик с работающих сервисов и их хранения (хотя запросто бывают и другие базы для этого)
- Grafana для отображения этих логов и сбора дашбордов.

Этими всё не ограничивается, регулярно появляются новые, какие-то отмирают.
Пожалуй, самая динамичная часть, тут не знаю что сказать: чтобы их быстро выучить, достаточно быть проактивным, заранее учить SQL и как работать с базами данных, очень в этом месте пригождается.

7. Какой-нибудь из инструментов оркестрации: чаще Kubernetes, реже Docker Swarm, почти никогда Apache Methos.

Тут shell почти никак не поможет, но знание Linux даёт нужную эрудицию, чтобы этих зверёв также быстро освоить.

Инструменты оркестрации помогают сильно абстрагироваться от конкретного железа, но начать воспринимать набор машин как связанный кластер (или набор кластеров) со всеми вытекающими: установка пакетов сразу на множество машин; настройка каскадов, чтобы машинки поднимались в правильной последовательности и многое-многое другое.

8. Хранилки для уже собранных артефактов: например, какой-нибудь Nexus SonarType (хотя есть разные). Это, обычно, самая простая часть.

9. Инструменты для работы с сетью.

Почему? Ну, потому что нынче всё в интернетах.

Тут всё очень по-разному, конкретные перечислять в этом месте смысла нет, но чем больше знаете про сетевые протоколы, тем всё проще и легче.

Догадаетесь на чём работают роутеры/маршрутизаторы/dns-сервера?

Какие инструменты используют DevOps-инженеры?
Часть 4 из ... про devops

10. Как правильно заметил Виктор в комментах (спасибо!), HashiCorp Terraform.

Почему? Потому что позволяет описать как должна быть развёрнута инфраструктура, но на довольно низком уровне.
Хочется настроить сеть сразу на множестве машин — там это можно; нужно написать сколько дисков и с каким разбиением выделяется вот этому набору виртуальных машин (на которые потом раскатится этот самый докер или куб, например) — там это можно. Да, кажется, всё, что угодно можно.

Но с небольшой оговоркой: терраформу нужен какой-нибудь провайдер виртуализации, на голое железо он не заедет без этого (см. OpenStack, Proxmox, VMWare VStack), если хочется совсем голое железо — то, опять же, Ansible и shell в руки и действуем. На облачных провайдеров из-за этого раскатывается также хорошо и бесшёвно.

Язык для описания довольно хороший (сильно лучше yaml), действительно человечный. Рекомендую глянуть, чтобы знать как нормально.

Но и небольшой дисклеймер: 1) их выкупил IBM, 2) они уже два года как забанили русских (а-та-та!)

ладна на этих выходных без постов, продолжу где-нибудь на днях

Кто такой DevOps? И какие у него есть друзья: MLOps

Часть 5 из ... про разный devops

Machine learning operations, акроним MLOps — это набор практик, направленных на последовательное и эффективное внедрение и поддержку моделей машинного обучения:
- через стандартизацию/унификацию релизного цикла;
- через автотесты;
- через CI и CD;
- через инструменты контейнеризации и оркестрации;

Кажется, слишком похоже на DevOps, да? Всё правильно поняли!

Инструменты точно такие же (почти), задачи такие же (почти), отличается только специфика или, правильнее сказать, доменная область (и зарплата, ведь в названии есть ML!!!): основной продукт, который сопровождают MLOps-инженеры -- это, как правило, модель машинного обучения.

Будучи MLOps можно ожидать, что будете ближе к данным, переливанию этих данных.
Сервисы, которые сопровождаются, будут связаны с этапами обучения/дообучения моделек и их валидации и тд.

Могут немного поменяться CD инструменты (Continuous Delivery, который про автоматическую доставку артефактов/релизов) под более специфичный для ML, но будет всё тот же линух, шелл-скрипты, тот же куб и докер (sic!) и теже терраформы. Знание сети также пригодится!

Ну и, конечно, пригодится знание доменной области, хотя бы поверхностно. Вот сейчас, например, все бегают с LLM, если примерно понимаете как они обучаются и работают — это всегда огромный плюс.


Не верите — на досуге открывайте хотя бы тот же hh.ru, вбивайте MLOps, сравнивайте сказанное с содержимым примерно любой вакансии.

А тут кружки Эйлера (вообще-то Венна, а совсем правильно Эйлера-Венна) про тоже самое.

Как обычно, круги Эйлера очень плохо подходят для точного описания (никогда не используйте их для понимания JOIN-ов в SQL, никогда!): здесь правильнее сместить MLOps сильно ближе к DevOps и совсем по верхам захватить ML, но чуть больше Data Engineering.

Но для обзора подойдут, ладна.

Котаны, постов не было, я старался отдыхать, а то силы у меня, оказывается, не бесконечные.

Вы, надеюсь, тоже отдыхать не забываете, лето всё-таки!


Пара хороших новостей:
- Регулярное вещание постепенно возвращаю.

- Я почти дописал курс на stepik по Unix.
Он мне не очень нравится, кажется, я в целом очень критичен к своим материалам, но скоро обязательно принесу вам его показывать.

- omp.wiki жива, хотя пролежала чуть больше месяца.
По аналитике вижу, что там время от времени бывают пользователи, пингуйте, если ляжет вновь.

Новых материалов там пока не появляется, но коплю на неё ресурс и к октябрю-ноябрю продолжу дописывать. Будем надеяться, что уже не только своими силами.


Серию постов про DevOps скоро закончу (правда-правда!), а пока держите небольшую годность.

Awesome!

Вот вам лайфхак: хотите по любому интересующему направлению быстро найти актуальные (и, скорее всего, популярные) книги, тулы, туториалы и пр.?

Вбивайте в гугле: awesome <тематика> github

Например, awesome ci github.

На гитхабе много таких репозиториев про что угодно: языки, фреймворки, иногда и по профессии в целом.

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


Например,
- https://github.com/krispo/awesome-haskell
- https://github.com/SE-ML/awesome-seml
- https://github.com/ligurio/awesome-ci


+ бывают мета-awesome списки, в смысле awesome списки awesome списков:
- https://github.com/fleveque/awesome-awesomes
- https://github.com/sindresorhus/awesome

Я, кстати, был неправ (никогда такого не было и вот опять), когда написал, что Ansible компилирует YAML в Shell.

Хорошо, что умные люди меня поправили на одном собесе.

Всё немного прозаичнее:
- Ansible старается использовать Python везде, где это возможно; в т.ч. для исполнения на конечном хосте; ну те натурально компилирует YAML в Python, отправляет его на конечный хост, там интерпретатором исполняет;
- В некоторых ситуациях, при этом, может пытаться использовать shell (или какой-нибудь PowerShell): некоторые задачи проще делать в нем и некоторые модули написаны на нем;


Суть меняется не особо, правда: представляете какой кошмар??

Как найти себя?

Когда-то обещал немного про софтовое, вот и про софтовое.
Мне это кажется очевидным, но очевидным для меня это было, кажется, не всегда.


Как найти себя? А никак.

Найти себя невозможно. Нет впереди такого места, где вы вдруг себя обнаружите крутыми и классными специалистами, просто пробуя перед этим всё подряд и тратя много активных лет на "поиски себя".

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


Можно, при этом, найти какие из навыков от природы вам легче прокачивать, а какие очень сложно. Выяснить в какой из навыков рандом уронил множитель x3, а в какой x0.1.

Быстрее выясните -- быстрее поймёте куда складывать дорогие и конечные поинты, очевидно. Вам про это потом и скажут: вы себя нашли.

Что почитать на каникулах?

К прочтению рекомендую такую вещь: The Architecture of Open Source Applications.

Внутри описания основных архитектурных решений разных опен-сурсных инструментов. Например, есть про ZeroMQ, nginx, git, Continous integration, Python packaging, Hadoop Filesystem.

Секцию 500 Lines or Less тоже смотреть обязательно, там краткие реализации разных прикольных программ и идей, можно взять код для начала своего интересного pet-проекта.


Короче, отличный источник для вдохновения и общей насмотренности.
#литература

Навигация

Для удобства и всех вновь прибывающих:

Харды
- Серия постов про DevOps: часть 1, часть 2, часть 3, часть 4, часть 5, часть 6.
- Посты про языки разметки: часть 1, часть 2, часть 3.

Софты
- Как стать крутым инженером?
- Как найти себя?

Материалы
- Подборка хороших авторских каналов по теме.
- Awesome: как быстро найти актуальную информацию по интересующей теме на github
- Архитектура разных open-source приложений

- omp.wiki — здесь вики, в которой собираются хорошие материалы, по которым читались курсы в Питерской Вышке и ИТМО. Сейчас там неплохо написана часть про Начальное окружение, она почти полная, остальное пишется.

Обсуждения
- Конечно, тёплый домашний чатик ОМП — там можно задать любые вопросы и обменяться котиками с другими котиками хорошими людьми, ищущими знания.


Этот пост будет обновляться

Как и обещано, пора заканчивать серию постов про DevOps и их друзей!

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


Постов будет еще примерно 3:

- про DevSecOps,
- про SRE,
- про неизбежную энтропию в жизни и индустрии;